| | <<<Back 1 day (to 2012/04/20) | 2012/04/21 |
| mvrhel | Robin_Watts and ray_laptop: for the logs. Setting the device to max separations when the number of spots on the page is unknown worked great | 05:33.58 |
| vtorri | hey | 07:34.17 |
| ghostbot | hola | 07:34.17 |
| vtorri | had mupdf been compiled for windows 64 bits ? | 07:34.57 |
| Robin_Watts | mvrhel: Fab. | 09:08.13 |
| | vtorri: Not by me, why? | 09:08.46 |
| vtorri | just a thought | 09:09.31 |
| | i'll soon build some 64 bits mingw packages for the project i'm involved in and mupdf is a dependency | 09:10.06 |
| Robin_Watts | vtorri: we build mupdf for 64bit unix every day. | 09:46.32 |
| | so I don't forsee mingw 64bit being a problem. | 09:46.51 |
| vtorri | Robin_Watts: well, i hope you don't assume that long is a 64 bits integer in mupdf :) | 10:09.16 |
| | is mupdf written in C89 ? | 10:09.31 |
| Robin_Watts | yes. | 10:09.46 |
| vtorri | good | 10:10.01 |
| | i ask again, for cross compilation wit mingw-w64 : i proposed that the OS value in Makerules be the host value, that is : | 10:11.20 |
| | i686-w64-mingw32 for mingw-w64 targetting Windows 32 bits | 10:11.42 |
| | x86_64-w64-mingw32 for mingw-w64 targetting Windows 64 bits | 10:11.55 |
| | is it good enough ? | 10:12.07 |
| | I can add -cross if you think it's needed | 10:12.31 |
| Robin_Watts | w64_amd64-cross-mingw32 and w64_x86-cross-mingw32 would have been my choices. | 10:26.21 |
| | but open a bug and add the patch, and we can talk to tor8 about the names on monday. | 10:26.58 |
| vtorri | btw | 10:34.48 |
| | in Makefile: | 10:34.52 |
| | CFLAGS += -Ifitz -Ipdf -Ixps -Icbz -Iscripts | 10:34.55 |
| | to be pedantic, it should be CPPFLAGS and not CFLAGS | 10:35.11 |
| | Robin_Watts: do you use a specific git command for the patches, or just the output of git diff ? | 10:36.41 |
| | draw/draw_affine.c:1:27: fatal error: fitz-internal.h: No such file or directory | 10:51.30 |
| | grmblll | 10:51.32 |
| | something wrong in your Makefile | 10:51.50 |
| sebras | vtorri: the -Ifitz in the CFLAGS-line you quoted just now, ought to solve that compilation error. | 11:47.18 |
| Robin_Watts | indeed. | 11:47.27 |
| | Do you have a fitz/fitz-internal.h | 11:47.39 |
| | You're the second person to report that recently, but the other person was a blithering idiot, so I ignored him. | 11:48.06 |
| sebras | Robin_Watts: make nuke && make worked fine on HEAD for me. | 11:48.26 |
| Robin_Watts | sebras: For me to. And the cluster. Hence me ignoring it. | 11:48.40 |
| vtorri | sebras: i know how to fix that | 11:49.10 |
| | sebras: but i should not do it myself | 11:49.21 |
| | Robin_Watts: yes | 11:49.25 |
| Robin_Watts | what is the problem then? | 11:49.33 |
| sebras | vtorri: no, but we don't know why you see the problem and we do not. | 11:49.38 |
| vtorri | I have to add -I./fitz/ | 11:49.47 |
| Robin_Watts | because you're compiling from a different directory ? | 11:50.02 |
| vtorri | but imho, it's the mupdf build system that should take care of that, not me | 11:50.12 |
| Robin_Watts | No, that can't be it. | 11:50.14 |
| sebras | vtorri: why is the CFLAGS line -Ifitz not enough for you? | 11:50.19 |
| Robin_Watts | Where do you have to add -I./fitz/ ? | 11:50.23 |
| vtorri | my command line : | 11:50.34 |
| | (in mupdf/ directory, taken from git) | 11:51.03 |
| | make OS=w64_x86-cross-mingw32 PATH="$HOME/local/opt/mingw-w64-x86_32/bin:$PATH" CFLAGS="-I$HOME/local/mupdf/include -I$HOME/local/mupdf/include/openjpeg-1.5 -I$HOME/local/mupdf/include/freetype2 -I./fitz" LIBS="-L$HOME/local/mupdf/lib -lopenjpeg -lfreetype -ljbig2dec -ljpeg -lz -lm" | 11:51.05 |
| | see the end of the CFLAGS value | 11:51.29 |
| | i added it there | 11:52.02 |
| Robin_Watts | Change CFLAGS to XCFLAGS in your invocation. | 11:52.06 |
| vtorri | ha | 11:52.12 |
| | and for LIBS ? | 11:52.17 |
| | XLIBS ? | 11:52.20 |
| Robin_Watts | hmm. We don't do the same thing for XLIBs. | 11:52.34 |
| | the makefile does: | 11:52.38 |
| | CFLAGS += $(XCFLAGS) -Ifitz -Ipdf -Ixps -Icbz -Iscripts | 11:52.57 |
| | I don't know why that doesn't properly append to cflags. | 11:53.10 |
| sebras | Robin_Watts: why doesn't the += work in this case? | 11:53.15 |
| | Robin_Watts: right. | 11:53.20 |
| Robin_Watts | I assume there is some make foo that I don't understand. | 11:53.22 |
| sebras | reading make manual. | 11:53.36 |
| Robin_Watts | I suspect one of the other makefiles assigns CFLAGS directly. | 11:55.01 |
| vtorri | ok, better | 11:55.35 |
| | but link problem, now | 11:55.40 |
| | command line : | 11:55.46 |
| | make OS=w64_x86-cross-mingw32 PATH="$HOME/local/opt/mingw-w64-x86_32/bin:$PATH" XCFLAGS="-I$HOME/local/mupdf/include -I$HOME/local/mupdf/include/openjpeg-1.5 -I$HOME/local/mupdf/include/freetype2" LIBS="-L$HOME/local/mupdf/lib" | 11:55.54 |
| | error: | 11:55.59 |
| sebras | Robin_Watts: from thirdparty you mean? no, that doesn't make sense. then none of mupdf would be able to compile... | 11:56.01 |
| Robin_Watts | nope, can't see any direct assignments. | 11:56.03 |
| vtorri | /home/torri/gitroot/mupdf/xps/xps_glyphs.c:41: undefined reference to `_FT_Set_Charmap' | 11:56.05 |
| | etc... | 11:56.06 |
| Robin_Watts | vtorri: clean rebuild. | 11:56.20 |
| vtorri | already did it | 11:56.31 |
| | but i try again | 11:56.35 |
| Robin_Watts | Why are you specifying any XCFLAGS ? | 11:56.58 |
| sebras | Robin_Watts: I think that when vtorri sets CFLAGS and LIBS like this, the += assignments in the toplevel Makefile are ignored, hence he is missing out on -lfreetype e.g. | 11:57.08 |
| Robin_Watts | ok, sorry, ignore me. | 11:57.09 |
| vtorri | see the command just above | 11:57.10 |
| sebras | Robin_Watts: I can not really say why (yet). | 11:57.26 |
| vtorri | indeed | 11:57.36 |
| Robin_Watts | vtorri: The problem is that your freetype is not matching ours, I suspect. | 11:57.39 |
| vtorri | when i set verbose: | 11:57.41 |
| | i686-w64-mingw32-gcc -o build/debug/mudraw build/debug/mudraw.o build/debug/libfitz.a -L/home/torri/local/mupdf/lib | 11:57.43 |
| | so no -l**** is passed | 11:57.55 |
| Robin_Watts | We supply a known version of our thirdparty libs, and we set up the paths to include them. | 11:58.17 |
| sebras | vtorri: test setting your variables like this CFLAGS=... LIBS=... make instead of setting them after. | 11:58.41 |
| | vtorri: I believe it makes a difference, but I do not know why yet. | 11:58.51 |
| vtorri | ok | 11:59.07 |
| Robin_Watts | That's the nicest solution. | 11:59.19 |
| | Otherwise you can try adding a $(XLIBS) to the LIBS += line at the top of Makefile in the same way as CFLAGS += has $(XCFLAGS) | 11:59.57 |
| | then set XLIBS on your command line. | 12:00.17 |
| vtorri | well, exporting CFLAGS and LIBS works (except another link problem, though) | 12:01.04 |
| sebras | Robin_Watts: ah, now I know. when you override a variable like vtorri is doing on the command-line (make CFLAGS=...) then all ordinary assignments of the same variable in the makefile are ignored. this is stated in the make manual. | 12:01.08 |
| Robin_Watts | Make foo FTW! | 12:01.45 |
| sebras | so I guess the basic message is to prepend variable instead of appending them, or to use XCFLAGS. | 12:02.06 |
| vtorri | that's something to add in README, imho | 12:02.11 |
| | and using XLIBS like XCFLAGS is also something to do | 12:02.28 |
| Robin_Watts | vtorri: I will commit the XLIBS thing. | 12:03.02 |
| sebras | vtorri: I'm surprised this problem has not bitten you (or me) before though. | 12:03.10 |
| | Robin_Watts: that makes sense, to complement XCFLAGS. | 12:03.22 |
| vtorri | sebras: that's the first time i cross compile mupdf | 12:03.29 |
| | usually, i compile it natively (windows or linux) | 12:03.53 |
| sebras | vtorri: I was not thinking only of mupdf. :) as this is a general problem for any make invocation. | 12:04.04 |
| vtorri | ho, well , i usually use autotools, so no real problem | 12:04.32 |
| | you're one of the few libs I compile which uses only make | 12:04.52 |
| sebras | vtorri: right. | 12:04.58 |
| Robin_Watts | pushed | 12:15.30 |
| vtorri | Robin_Watts: XLIBS works :) | 12:24.00 |
| | so last error: | 12:24.09 |
| | /home/torri/gitroot/mupdf/fitz/image_jpx.c:52: undefined reference to `_opj_set_default_decoder_parameters' | 12:24.16 |
| | and similar | 12:24.20 |
| | i have openjpeg | 12:24.27 |
| | i've compiled it myself (like the other libs) | 12:24.41 |
| | the symbol exists | 12:24.53 |
| sebras | vtorri: and -lopenjpeg is included in the resulting LIBS? | 12:25.19 |
| vtorri | example: | 12:25.24 |
| | 00000000 I _imp__opj_image_destroy@4 | 12:25.26 |
| | 00000000 T opj_image_destroy@4 | 12:25.26 |
| | sebras: yes | 12:25.30 |
| | note the @*** | 12:25.36 |
| | it's not in the symbols of other libs | 12:25.55 |
| | also, i compiled openjpeg 1.5 | 12:26.03 |
| | (the last one) | 12:26.18 |
| Robin_Watts | You will need 1.5, I believe. | 12:26.19 |
| sebras | vtorri: I think our latest thirdparty package uses 1.5 as well. | 12:26.22 |
| vtorri | hmmm | 12:26.27 |
| sebras | vtorri: though the @ makes me think of c++... | 12:26.36 |
| vtorri | me too | 12:26.47 |
| | but i'm not sure at all | 12:26.52 |
| | and i know that openjpeg is written in C | 12:27.07 |
| | maybe another calling convention | 12:27.21 |
| | stdfcall or something else | 12:27.35 |
| sebras | vtorri: nm build/debug/image_jpx.o on my linux-build lists opj_set_default_decoder_parameters without any @ though. | 12:28.09 |
| vtorri | i'll ask that in the mingw-w64 chan | 12:28.45 |
| sebras | vtorri: could it be that you built the library using g++? | 12:28.50 |
| vtorri | i don't think so | 12:29.04 |
| sebras | vtorri: I'm not sure whether that would matter, so it's just a hunch. | 12:29.07 |
| vtorri | autotools are used | 12:29.09 |
| | and tehy choose the compiler wrt the file extension | 12:29.23 |
| | they* | 12:29.30 |
| | i'm quite sure what it is done, as i've written these autotools :) | 12:29.55 |
| sebras | vtorri: ok, anyway I think it may be when you compiled openjpeg that something went awry. not sure what caused it since I can not reproduce. | 12:34.08 |
| vtorri | ok | 12:35.44 |
| naveen_ | Hey Robin...Can you tell me If I'm aceesing fz_aes correctly? http://pastebin.com/dCiKz74c | 12:50.25 |
| Robin_Watts | looks plausible. | 12:51.51 |
| naveen_ | but decryption is not working if I access fz_aes from rimage_aesd_s... | 12:53.06 |
| Robin_Watts | naveen_: I can't see where aes is defined. | 12:54.35 |
| | ah, yes I can. | 12:54.40 |
| | Right, that's the problem. | 12:54.44 |
| | oh, maybe not. | 12:55.12 |
| naveen_ | that has some problem.... | 12:55.34 |
| | if I access it directly then it is working... | 12:56.09 |
| | i.e not from rimage_aesd | 12:56.25 |
| Robin_Watts | In fz_open_encrypted_file you define aes as a local variable. | 12:56.26 |
| | This means it's on the stack. | 12:56.30 |
| naveen_ | ok..will try that.. | 12:56.56 |
| Robin_Watts | When you do state->aes = aes, you copy the value of aes into state->aes. | 12:56.58 |
| | I haven't given you anything to try yet - I'm just describing the state of your code at the moment. | 12:57.23 |
| | If you then do anything else with aes, that will not be reflected in the stored value. | 12:57.45 |
| | Personally, I'd remove "fz_aes aes;" from fz_open_encrypted_file. | 12:58.22 |
| | And change the operations on &aes to be operations on &state->aes (you'll need to move the aes_setkey_dec down a bit. | 12:59.01 |
| | Does that make sense? | 12:59.05 |
| naveen_ | you mean after assigning state->aes | 12:59.56 |
| Robin_Watts | I mean there is no longer any need to assign state->aes. | 13:01.30 |
| | You do aes_setkey_dec(&state->aes, ...); | 13:01.52 |
| | so you operate on that directly. | 13:01.57 |
| naveen_ | ok.... | 13:02.29 |
| vtorri | sebras: i have to force the compilation of openjpeg as static | 13:03.51 |
| | otherwise the calling convention is stdcall | 13:04.10 |
| | now it works | 13:04.27 |
| naveen_ | thanks..it works now... | 13:05.08 |
| sebras | vtorri: aha. I didn't know that this affected symbol names. | 13:05.09 |
| naveen_ | Robin,you work on weekends too? | 13:05.51 |
| vtorri | sebras: are you interested in warning during the compilation ? | 13:06.16 |
| sebras | vtorri: I know we get a few sometimes, but put the log on pastebin I'll compare it to those we normally have. | 13:07.20 |
| | vtorri: most of the ones we have are in the thirdparty dependencies. | 13:08.27 |
| vtorri | http://codepad.org/aNabLD7I | 13:10.31 |
| | the compilation flags are in XCFLAGS (first line) | 13:10.45 |
| | i'll give you the one without -Wshadow in a few seconds | 13:11.39 |
| | http://codepad.org/JRckrBF7 | 13:12.26 |
| sebras | vtorri: ok, thanks. | 13:13.10 |
| vtorri | you're welcome | 13:13.30 |
| Robin_Watts | vtorri: Well, I've spotted and fixed one bug from that, thanks :) | 13:14.18 |
| vtorri | yw | 13:14.31 |
| | btw, it's gcc 4.7 | 13:14.38 |
| sebras | Robin_Watts: pdf_meta? | 13:14.39 |
| Robin_Watts | yeah. | 13:14.44 |
| sebras | Robin_Watts: I did too, I was just about to tell you that I have a patch... ;) | 13:15.00 |
| Robin_Watts | I'm off to watch the F1 qualifying. bbl. | 13:15.03 |
| | naveen_: on and off. I work from home, so when I'm sat at my PC, I see messages. | 13:15.35 |
| sebras | Robin_Watts: I should already be downtown... thanks vtorri. :) | 13:15.38 |
| vtorri | bug #692997 sublitted | 14:42.29 |
| | -l°m | 14:42.34 |
| | + | 14:42.36 |
| | can i ask questions about jbig2dec here ? | 16:35.10 |
| sebras | vtorri: I had a quick look at your patch. may I ask why you feel that you need to point to openjpeg and freetype that you built on your own? | 17:17.01 |
| | vtorri: is there something in the buildprocess (when building just mupdf) that does not work for you? | 17:17.24 |
| | or is it just about building the mupdf-library and then linking that to an app of your own? | 17:17.42 |
| vtorri | that command line is just about building mupdf | 17:19.14 |
| | i know that openjpeg.h is in 2 dirs | 17:19.33 |
| | $prefix/include and $prefix/include/openjpeg-1.5 | 17:19.48 |
| | doing that is an error | 17:19.55 |
| sebras | vtorri: ok, but that's not really what I meant. | 17:20.18 |
| vtorri | well | 17:20.42 |
| | what did you lean, then ? | 17:20.48 |
| | i'm cross compiling on linux, targeting windows | 17:21.02 |
| | so i have to compile the deps myself | 17:21.13 |
| sebras | I was wondering more along the lines of why make OS=w64_x86-cross-mingw32 does not work as is? why to you need to set XLIBS and XCFLAGS? | 17:21.21 |
| vtorri | and where will gcc find the header files of zlib, etc... ? | 17:22.04 |
| | i have to tell him where they are | 17:22.12 |
| | /s/him/it | 17:22.22 |
| sebras | in a normal non-cross-compiling build the mupdf Makefile builds the dependencies and links them statically to the mupdf binaries. like freetype, openjpeg, jbig2dec, libjpeg, zlib... | 17:22.41 |
| | this is why I'm a bit puzzled. do you see where I'm coming from? | 17:23.00 |
| vtorri | ok | 17:23.13 |
| | i'm currently on linux | 17:23.18 |
| | i want a mupdf library that will work on windows | 17:23.32 |
| | so i cross compile it | 17:23.41 |
| | mupdf needs some dependencies | 17:23.49 |
| | for example zlib | 17:23.56 |
| | of course, the linux zlib can not be used | 17:24.08 |
| | so i have to also cross compile zlib | 17:24.17 |
| sebras | yes. | 17:24.30 |
| vtorri | and I install it somewhere | 17:24.35 |
| | the directory where i install it is not important | 17:24.49 |
| | i have chosen $HOME/local/mupdf | 17:25.00 |
| sebras | but in a native-compiling case zlib is build and linked to the mupdf binary by the mupdf Makefile. | 17:25.02 |
| vtorri | and , | 17:25.22 |
| | ? | 17:25.23 |
| | i'm not doing native compialtion | 17:25.32 |
| | sorry, I don't understand what you want to tell me | 17:26.05 |
| sebras | sure, I follow your reasoning. :) but I'm getting the feeling that you are missing out on that mupdf builds the thirdparty libraries. at least in a native build. I haven't tried in a cross-compiling build, but maybe it would be a good idea to tackle that problem (thereby eliminating the need to set XCFLAGS and XLIB). | 17:26.10 |
| vtorri | ok | 17:26.38 |
| sebras | in the top-level README there is a section on COMPILING. | 17:26.48 |
| vtorri | so maybe i don't know what the third party libs are | 17:26.51 |
| | 2s, i read it | 17:27.01 |
| sebras | there we write about a mupdf-thirdparty.zip that you can unzip in the same build directory to have mupdf build the dependencies automagically. | 17:27.14 |
| | I'm thinking that doing this would eliminate the need to set variables on the command line (possibly even in a cross-compiling build). | 17:27.42 |
| vtorri | they are pre-built ? | 17:27.59 |
| sebras | the patch that you sent in your bug would still be valid though. | 17:28.02 |
| | vtorri: no. | 17:28.05 |
| | mupdf-thirdparty.zip contains source files. | 17:28.14 |
| vtorri | then i don't now how you manage, for example, the cross compilation of zlib | 17:28.28 |
| sebras | so we actually build the dependencies from source to static libraries which are then linked to the mupdf binary. | 17:28.33 |
| vtorri | because you *have* to modify Makefile.gcc in zlib/win32 | 17:28.53 |
| sebras | I'm not convinced that we use the zlib packages own makefile. | 17:29.13 |
| vtorri | and the modifications depends on the toolchain you use | 17:29.19 |
| sebras | look in Makethird in mupdf. | 17:29.27 |
| vtorri | ha | 17:29.51 |
| sebras | I believe that we just list the source files we know we need, and build a static library from those. | 17:29.52 |
| vtorri | ok | 17:29.59 |
| | you do that way | 17:30.06 |
| | ok | 17:30.08 |
| sebras | I might not be explaining it very well, but I'm trying to minimize the kludges you need to do in order to build at least. :) | 17:30.50 |
| vtorri | that's a not common way to build stuff | 17:31.18 |
| | but ok | 17:31.21 |
| | one thing : | 17:31.26 |
| | the libraries are not up to date | 17:31.33 |
| sebras | no, it's not. I know. :) | 17:31.34 |
| | vtorri: ok, that's a good point. which library is there a later version of? | 17:31.47 |
| vtorri | freetype 2.4.9 is released | 17:31.48 |
| | zlib 1.2.6 too | 17:31.53 |
| | about jbig2dec, i don't know which one you use | 17:32.13 |
| sebras | I believe that jbig2dec is a local version. basically there is no upstream (or rather ghostscript _is_ the upstream nowadays AFAIK). | 17:32.52 |
| vtorri | what annoys me with static linking like you did is that you can loose some memory | 17:33.36 |
| | for example, in our project, we already use alls the deps except jbig2dec | 17:33.59 |
| sebras | vtorri: right. | 17:34.06 |
| vtorri | so we loose the share of these libs | 17:34.11 |
| sebras | yes, you would. there have been some requests for shared libraries, but so far no one has contributed a patch to build them. | 17:34.52 |
| vtorri | but i guess that, until mupdf itself is not a shared lib, it will stay like that | 17:35.03 |
| sebras | and as you probably have seen we've been working on other stuff to make sure 1.0 gets out. | 17:35.23 |
| vtorri | "to build them" <-- them == ? | 17:35.28 |
| sebras | them == the shared libraries. | 17:35.46 |
| vtorri | of the dependencies ? | 17:35.53 |
| sebras | vtorri: I installed mingw-w64 on my debian/testing box, downloaded mupdf-thirdparty.zip, unzipped it and then ran make nuke; make OS=w64_x86-cross-mingw32 after applying your patch. I got a windows binary. | 17:36.54 |
| | vtorri: of mupdf itself. | 17:37.01 |
| vtorri | ho | 17:37.07 |
| | well, last time i asked tor about that, he didn't want to because the API was not stable, which is a good point, of course | 17:37.39 |
| sebras | vtorri: so I'm hoping that you will be able to build like this as well. but you still may want to do it by building the dependencies on your own for other reasons of course. :) | 17:37.58 |
| vtorri | hehe, of course i have my own reasons | 17:38.23 |
| | because the project i'm involved in need them anyway :) | 17:38.38 |
| | except jbig2dec | 17:38.53 |
| | can you try with mingw-w64 targetting win 64 ? | 17:39.11 |
| | because i had a problem with jbig2dec | 17:39.26 |
| sebras | sure. anyway I hope you get the intention of how to use thirdparty now anyway. I just wanted to make sure that got across incase it solved your problem. | 17:39.26 |
| vtorri | well, i didn't know that the build worked that way | 17:39.57 |
| | i have to buy some food | 17:42.11 |
| | bbl | 17:42.15 |
| | :) | 17:42.18 |
| sebras | bb. | 17:42.26 |
| vtorri | back | 18:06.40 |
| | question about the build of the lib that i'm the maintainer and which uses mupdf | 18:07.33 |
| | do you think that providing mupdf source code inside the lib's tree is a good idea ? | 18:07.57 |
| | i don't see any other alternative as mupdf is not distributed with the linux distros | 18:08.27 |
| sebras | vtorri: mupdf is distributed in debian at least. | 18:30.33 |
| | as a library as well as far as I know. but I may be wrong. | 18:30.55 |
| vtorri | not in my ubuntu, but it's more that 1 year old | 18:40.20 |
| | 1.5 year, actually | 18:40.30 |
| sebras | vtorri: mm, it was a added relatively recently to ubuntu. | 18:43.54 |
| vtorri | ok | 18:44.32 |
| | the fact is, it is recent and i can't rely on people having the latest distros | 18:44.57 |
| | Forward 1 day (to 2012/04/22)>>> | |
IRC Logs