| | <<<Back 1 day (to 2014/09/19) | 2014/09/20 |
| marcosw1 | chrisl_away, et.al.: testing of rc2 is complete and we are go for launch. | 03:39.03 |
| NhocKun | hey guy, can i change animation when read pdf file using mupdf for android | 04:26.40 |
| | some body hear me .. | 04:29.34 |
| hdon | been pretty quite here for a while NhocKun, be patient :) | 04:35.05 |
| NhocKun | :D ok | 04:37.10 |
| Amyn | Hey I am using GS 9.14 for PDF to Image Conversions. I get the following error when my application calls gswin32c.exe multiple times | 07:24.57 |
| | Robin_Watts: I saw IRC logs and I see someone already brought forward this error and you were looking into it | 07:26.10 |
| Robin_Watts | Amyn: What error? | 07:54.09 |
| Amyn | "C++ Runtime error R6016 -not enough space for thread data" | 08:12.30 |
| chrisl_away | I believe I now have the Windows installer for ghostscript working how I want - yay! | 12:26.31 |
| Robin_Watts | excellent. | 12:46.49 |
| artf | What tools do you use to view the ttfs created by mubusy extract? | 15:26.56 |
| Guest91436 | Hi guys. I'm trying to compile mupdf1.5 from source for use with zathura-pdf-mupdf. after making/installing mupdf, i tried to build zathura-pdf-mupdf, and got an error that told me i need to compile mupdf with -fPIC. I did so by adding it in the Makerules, but now when compiling zathura-pdf-mupdf, I get two errors from ld, in particular "cannot find -lmupdf-js-none" and "cannot find -lopenjp2". Not sure how to proceed from here | 15:31.39 |
| ivanshmakov | Guest91436: For the latter one, I guess you need the OpenJPEG library installed. | 15:57.43 |
| Robin_Watts | openjp2 is the openjpeg lib. | 16:09.52 |
| | mupdf-js-none.c is a file that you're obviously not compiling. | 16:10.04 |
| Guest91436 | Thank you ivanshmakov and Robin_Watts. I changed the makefile to use -lmujs and -lopenjpeg instead, and now zathura-pdf-mupdf compiles. Unfortunately when I open a pdf in zathura, I get the error "(/usr/lib/zathura/pdf.so: undefined symbol: opj_stream_set_user_data_length)", looks like a problem with OpenJPEG | 16:24.23 |
| | I have a link "/usr/lib64/libopenjpeg.so -> libopenjpeg.so.2.0" in /usr/lib64/, so I would think that it would be ok to replace -lopenjp2 with -lopenjpeg, is that right? | 16:28.21 |
| ivanshmakov | Guest91436: Looks like it is. | 16:37.04 |
| Guest91436 | ivanshmakov: any idea why I would be getting that error then? (I'm still relatively new to building software from source. I really appreciate your help :)) | 16:38.28 |
| ivanshmakov | Guest91436: Difference between the library versions, perhaps? | 16:41.12 |
| | Guest91436: I do not completely understand what you do, but did you note that the error comes from the file (/usr/lib/zathura/pdf.so) under /usr/lib?âThat ought to be the version of zathura/pdf.so that comes with your distribution; the version youâve built yourself (if you indeed did that) should reside under /usr/local/lib (or /home/jrh/lib, or something like that.) | 16:42.07 |
| Guest91436 | ivanshmakov: my distro (opensuse) doesn't have zathura in its official repos, so I'm built it from source, and make install placed the mupdf plugin (pdf.so) in /usr/lib/zathura | 16:44.57 |
| ivanshmakov | Guest91436: ACK.âBut remember that /usr should generally be only managed via a package manager. | 16:46.35 |
| | Guest91436: Examine the output of $ ldd -- /usr/lib/zathura/pdf.so, â it may reference the versions of the libraries other than it was built against. | 16:47.56 |
| | Guest91436: Do I understand it correctly that you took the version of OpenJPEG that comes with your distribution, BTW? | 16:48.36 |
| Guest91436 | ivanshmakov: ok, thanks for the tip. I ran ldd on the file, not exactly sure how to interpret the output. yes, OpenJPEG came with my distro | 16:49.26 |
| ivanshmakov | Guest91436: Was there /usr/lib64/libopenjpeg.so.2.0 in the output? | 16:50.00 |
| | (Using /usr/local or oneâs own HOME directory for the software built by oneself also gives a hint to us, the community, about whatâs going on, BTW.) | 16:50.30 |
| Guest91436 | ivanshmakov: ldd shows the following: libopenjpeg.so.2.0 => /usr/lib64/libopenjpeg.so.2.0 (0x00007fcada9b6000) | 16:52.29 |
| | ivanshmakov: ok, I'll keep that in mind. I've been installing software using sudo make install. is there a simple way to have it put the files in /usr/local or in my home dir? | 16:53.22 |
| ivanshmakov | Guest91436: When the software employs a build system based on GNUÂ Autotools, â itâs just a matter of passing â--prefix="$HOME"â (or /usr/local) to âconfigureâ. | 16:56.25 |
| | Guest91436: If it doesnât, then check Makefile for a variable called âprefixâ (may be referenced from a âbindirâ variable) or something like that. | 16:57.31 |
| | Naturally, when installing under oneâs own HOME, no âsudoâ is necessary. | 16:57.58 |
| | Guest91436: Is it possible that youâve â.hâ files for one OpenJPEG version while libopenjpeg.so.2.0 comes from another? | 16:59.50 |
| Guest91436 | ivanshmakov: I suppose that's possible, i have the packages openjpeg-devel and openjpeg2-devel both installed | 17:05.20 |
| ivanshmakov | Guest91436: Examine the versions of these packages and the lists of files for each. | 17:05.57 |
| | Guest91436: The preprocessor flags for your build may need to be adjusted to use -I/where/is/the/right/version.â(Assuming that the linker flags already reference the proper version with -lopenjpeg.) | 17:08.11 |
| Guest91436 | ivanshmakov: ah ha, there is a link "/usr/include/openjpeg.h -> openjpeg-1.5/openjpeg.h", so it appears that the header used was for openjpeg 1.5 and the .so is for version 2.0 | 17:09.24 |
| ivanshmakov | Guest91436: So my guess is that you have to use -I/usr/include/openjpeg-2.0 (assuming such a directory indeed exists and contains the necessary .h files.) | 17:10.31 |
| Guest91436 | ivanshmakov: hmm, wasn't able to resolve the problem. I tried using -I/usr/include/openjpeg-2.0, and even tried pointing that symlink to be "/usr/include/openjpeg.h -> /usr/include/openjpeg-2.0/openjpeg.h" but still having the same issue | 17:18.15 |
| ivanshmakov | Guest91436: Did you re-build the code completely anew? | 17:19.52 |
| Guest91436 | ivanshmakov: i rebuilt zathura-pdf-mupdf (the source that creates pdf.so) and installed it | 17:20.57 |
| ivanshmakov | Guest91436: It may be better to remove the symlink altogether while troubleshooting this issue.âFWIW, the lack of the symlink may provoke errors at build-time, if that â-Iâ somehow gets missed by the build process. | 17:21.29 |
| Guest91436 | ivanshmakov: ok, I removed the symlink, and rebuilt/reinstalled. there were no compile errors, so it appears that the '-I' worked okay, but the issue remains | 17:24.35 |
| ivanshmakov | Guest91436: At this point, Iâd check the mtime for /usr/lib/zathura/pdf.so, and also run $ grep -rlF -- opj_stream_set_user_data_length over the build directory. | 17:26.42 |
| | (To see if pdf.so really got replaced, that is.) | 17:27.04 |
| Guest91436 | ivanshmakov: interestingly, even if I remove that "-I", it still compiles. I checked the mtime for /usr/lib/zathura/pdf.so and its recent (just a couple of minutes ago) | 17:28.50 |
| | ivanshmakov: the grep command just returns pdf.so | 17:29.36 |
| ivanshmakov | Guest91436: Is that pdf.so in your build directory?âThere, the reference shouldâve been brought from an .o file, so Grep shouldâve found that one just as well. | 17:31.14 |
| Guest91436 | ivanshmakov: I also ran "find /usr -name "openjpeg.h" " to see if the compiler was finding one somewhere else, and the only two openjpeg.h files are in /usr/include/openjpeg-1.5 and /usr/include/openjpeg-2.0 | 17:31.34 |
| | ivanshmakov: yes, that's in the build dir with all of the .o files, and it was only found in pdf.so | 17:32.28 |
| ivanshmakov | Guest91436: Is that pdf.so also recent? | 17:32.45 |
| Guest91436 | ivanshmakov: yes it is | 17:34.42 |
| ivanshmakov | Guest91436: Itâs possible that the code actually knows that .h by a different name; did you check if there indeed are any â#include <openjpeg.h>â lines in the code? | 17:34.53 |
| | Guest91436: Frankly, I have no idea how a â.soâ may reference a function while the â.oâs itâs linked from lack such a reference. | 17:35.58 |
| Guest91436 | ivanshmakov: yes I'm confused too, I ran "grep -rlF openjpeg.h", and it also appears only in pdf.so. is it possible that pdf.so's dependence on opj_stream_set_user_data_length is coming from the mupdf library? (not sure if that even makes sense) | 17:38.17 |
| ivanshmakov | Guest91436: Itâs certainly possible.âYou can run $ ldd on the MuPDF .so to check it out, BTW. | 17:40.04 |
| Guest91436 | ivanshmakov: I don't have a mupdf .so, just a libmupdf.a. is that a problem? | 17:42.01 |
| ivanshmakov | Guest91436: Well, you can run grep over .a; ldd is specific to .so, though. | 17:43.16 |
| Guest91436 | ivanshmakov: it appears that mupdf is building its own libopenjpeg.a, and it contains opj_stream_set_user_data_length | 17:46.40 |
| | ivanshmakov: by the way, I also built mupdf from source | 17:46.52 |
| ivanshmakov | Guest91436: âContainsâ as in âthereâs ât opj_stream_set_user_data_lengthâ somewhere in the $ nm -- libopenjpeg.a outputâ? | 17:48.32 |
| | Guest91436: If at all possible, Iâd try to force MuPDF to use the system version of the library. | 17:49.20 |
| Guest91436 | ivanshmakov: sorry, by contains I meaned I grep'ed opj_stream_set_user_data_length, and it appeared in libopenjpeg.a (and libmupdf.a, and some .o files) | 17:50.45 |
| ivanshmakov | Guest91436: If you can, try to make MuPDF use the system version of libopenjpeg.so. | 17:51.30 |
| Guest91436 | ivanshmakov: I tried using mupdf from the official repos, but I think it was an old version, because it didn't have files like mupdf/pdf.h and mupdf/fitz.h in /usr/include | 17:52.42 |
| | ivanshmakov: ok, I'm not sure off hand how to do that though | 17:53.29 |
| ivanshmakov | Guest91436: Did you install the respective -devel package?â(Did it have /any/ .h files under /usr/include/mupdf?) | 17:53.31 |
| Guest91436 | ivanshmakov: yes, i had the -devel package, and it had .h files but they weren't the same structure as the ones called for in zathura-pdf-mupdf | 17:54.17 |
| | ivanshmakov: so I'm assuming it was an older version | 17:54.29 |
| ivanshmakov | Guest91436: My guess is that libmupdf.a youâve got is linked against OpenJPEGÂ 1, while the Zathura pdf.so is linked to OpenJPEGÂ 2 /and/ (indirectly, via libmupdf.a) to OpenJPEGÂ 1, â which /means/ trouble. | 17:54.58 |
| | Guest91436: ACK. | 17:55.03 |
| | Guest91436: You may try to temporarily remove (rename) thirdparty/openjpeg/libopenjpeg/CMakeLists.txt while building MuPDF, BTW. | 17:58.55 |
| Guest91436 | ivanshmakov: ok, trying that now. what does CMakeLists.txt do btw? | 17:59.57 |
| ivanshmakov | Guest91436: No idea; something related to CMake, presumably (if CMake is indeed used to build the OpenJPEG library.) | 18:00.44 |
| Guest91436 | ivanshmakov: ok. now when i try to make mupdf it complains that it can't find package libopenjp2 and that I should add the directroy containing libopenjp2.pc to PKG_CONFIG_PATH. I don't think I have libopenjp2.pc though... | 18:02.07 |
| ivanshmakov | Guest91436: I guess it may be called openjpeg2.pc or something like that in your system; check /usr/lib/pkgconfig. | 18:05.03 |
| Guest91436 | ivanshmakov: i'll try changing libopenjp2 to libopenjpeg in the mupdf Makerules | 18:05.16 |
| ivanshmakov | Guest91436: Either that or symlink the existing file to the non-existing alias MuPDF refers to. | 18:05.49 |
| Guest91436 | ivanshmakov:ok, I'm not sure what a .pc file is though | 18:06.56 |
| | ivanshmakov: yikes, mupdf doesn't appear to be compatible with the system openjpeg, i get all kinds of errors like "unknown type name OPJ_SIZE_T" | 18:09.16 |
| | ivanshmakov: when trying to compile, that is | 18:09.34 |
| ivanshmakov | Guest91436: A .pc file lists the compiler and linker flags necessary to link against some library.âAs that generally boils down to -lLIBRARYNAME /and/ that these library names tend to differ just the same as the .pc file names do, â Iâd say thatâs not exactly an effective measure to simplify builds. | 18:09.39 |
| | Guest91436: A similar issue was found and resolved in https://bugs.debian.org/743103.âThe bug report doesnât mention the details or the patch, though. | 18:13.19 |
| Guest91436 | ivanshmakov: ah ok, thanks. perhaps I should try to link zathura-pdf-mupdf to the version of openjpeg used in mupdf rather than try to get both to link to my system ones? | 18:13.54 |
| ivanshmakov | Guest91436: Makes sense, yes. | 18:14.23 |
| | Guest91436: Then youâd need to point your zathura-pdf-mupdf building process at the directories the respective .h (-I) and .a (-L) files reside under. | 18:15.02 |
| Guest91436 | ivanshmakov: ok. it looks like mupdf doesn't build a .a for openjpeg by default though, I'll have to figure out how to do that | 18:19.34 |
| ivanshmakov | Guest91436: Didnât you say it earlier that youâve found libopenjpeg.a under the MuPDF build tree? | 18:20.43 |
| | Guest91436: Naturally, libopenjpeg.so would fit just fine, too. | 18:21.02 |
| Guest91436 | ivanshmakov: sorry, you're right, it has a libopenjpeg.a :) | 18:23.49 |
| | ivanshmakov: man... now it's "undefined symbol opj_setup_decoder" | 18:40.17 |
| | ivanshmakov: strange though, mupdf's version of openjpeg.h has opj_setup_decoder... | 18:45.01 |
| ivanshmakov | Guest91436: And what about $ nm -- libopenjpeg.a?âDoes it list opj_setup_decoder, too? | 18:46.44 |
| | Guest91436: Be sure that youâre linking against the intended version of the library, too. | 18:46.58 |
| Guest91436 | ivanshmakov: nm -- libopenjpeg.a has "0000000000000522 T opj_setup_decoder", so should be there, must be i'm not linking against the intended library. could i check that using ldd on pdf.so? | 18:49.42 |
| ivanshmakov | Guest91436: Yes, kind of: if your $ ldd -- pdf.so output mentions libopenjpeg.so, â itâs linked against the systemâs version (perhaps together with the MuPDF OpenJPEG .h files.) | 18:53.14 |
| Guest91436 | ivanshmakov: ok, even if I remove the "-I" and "-L" from config.mk in the zathura-pdf-mupdf dir, it can still compile, so I'm assuming it isn't using the .h and .a from my mupdf source dir. is there a way to ensure that it uses those? | 18:53.41 |
| ivanshmakov | s/together with/while using/, etc. | 18:53.42 |
| | Guest91436: Examine the $ make output carefully; it should show all the âgccâ commands in the plain. | 18:54.28 |
| | Guest91436: Itâs possible that it compiles both with and without -I, -L because it can use either version of the library, BTW. | 18:55.15 |
| Guest91436 | ivanshmakov: when i run make, it lists the CFLAGS. none of them have /usr/include/openjpeg, but it still compiles somehow | 18:59.45 |
| ivanshmakov | Guest91436: Make shows the commands it executes by default.âIt became somewhat of a trend in the recent years to hide them via Makefile code, but it should be possible to get it back with something like a V=1 option to $ make, or something like that. | 19:02.59 |
| | Guest91436: The build systems differ somewhat when it comes to the variable names; for instance, the -I options are commonly to CPPFLAGS, â not CFLAGS. | 19:03.51 |
| | (Especially if thereâre some other languages that use the C preprocessor in the build.) | 19:04.59 |
| | Guest91436: Anyway, does libopenjpeg.so.2.0 get mentioned in the $ ldd -- pdf.so output? | 19:05.52 |
| Guest91436 | ivanshmakov: ok, I set VERBOSE ?= 1 , and now it outputs a bunch of cc commands | 19:06.13 |
| ivanshmakov | Guest91436: Are the relevant -I, -L options indeed passed correctly? | 19:06.55 |
| Guest91436 | ivanshmakov: none of them have a -I for openjpeg though, and yet it still compiles. I'll try putting the path to the .h and .a and see if they appear there | 19:07.16 |
| | ivanshmakov: ok, the paths I specified are now there. btw, should I be using -l or -L? | 19:08.53 |
| ivanshmakov | Guest91436: -l gives the âbase nameâ of the file, and -L gives the directory. | 19:14.56 |
| | Guest91436: Say, for linking against /where/is/libfoo.so, you use -lfoo -L/where/is. | 19:15.16 |
| | Guest91436: That part about openjpeg.h is strange, though. | 19:15.48 |
| Guest91436 | ivanshmakov: oops, I had included the file name in my -L command. fixed that and now zathura-pdf-mupdf works!! | 19:24.19 |
| | ivanshmakov: thank you so much for your time. I never would have figured this out on my own. learned a lot from you :) | 19:24.36 |
| ivanshmakov | Guest91436: Youâre welcome. | 19:29.57 |
| | Forward 1 day (to 2014/09/21)>>> | |
IRC Logs