| <<<Back 1 day (to 2018/06/14) | 20180615 |
hid | hello, I want to compile mupdf to work with zathura-mupdf plugin | 11:52.03 |
| I need to add the compilation option -fPIC in the Makefile but where and how? | 11:52.36 |
tor8 | hid: make XCFLAGS=-fPIC | 11:53.00 |
| paulgardiner: updated tor/ui which matches adobe much better on the Commision_Revision_Request pdf. | 11:53.51 |
hid | ah yes I always have this fitz error when compiling, is it some package I have to instal? | 11:53.55 |
tor8 | hid: mupdf does not support building a shared library from the stock makefile. we don't endorse shared libraries, since we want to be able to change the ABI without worrying about breaking things. | 11:55.13 |
| hid: so projects like Zathura which (against our advice) insist on using shared libraries, must do so at their own peril. | 11:55.53 |
| hid: I'm surprised zathura doesn't provide a build script for building mupdf. | 11:56.41 |
avih | tor8: any idea how to bypass using readline in mujs? | 12:20.20 |
| i'd suggest disabling it by default since you don't have configure | 12:21.17 |
tor8 | avih: fair enough. try tor/master; disable by setting HAVE_READLINE=no and force it enabled by setting HAVE_READLINE=yes | 13:06.04 |
avih | tor8: looks like it'd work, but it still enabled -ffunction-sections -fdata-sections iff uname prints Linux | 13:07.57 |
| enables* | 13:08.06 |
tor8 | and why is that a problem for you? | 13:10.54 |
avih | don't know, but it appears that you'd only want it for linux, which clearly is not always the case | 13:11.50 |
tor8 | I guess they're not really needed in the first place | 13:11.58 |
| they only help when linking the 'mujs' shell binary, not when using the library (unless the client also sets those flags, which is unlikely) | 13:12.24 |
avih | (i don't know what these cflags and ldflags do) | 13:12.25 |
tor8 | they allow the linker to drop individual unused functions | 13:13.27 |
| normally it only drops entire compilation units | 13:13.36 |
avih | oh | 13:13.43 |
tor8 | it adds 8kb of unused code (uncalled debug functions) to the final binary | 13:13.59 |
| they're useful to have when running in gdb to debug print data structures, etc | 13:14.26 |
avih | hmm.. if the debug functions are not called in "debug mode", why even compile them in the first place? | 13:14.32 |
tor8 | since you can call functions from the gdb shell | 13:14.35 |
avih | not called in "normal" mode | 13:14.47 |
| oh, i see | 13:14.54 |
| i'd think it'd be ok to compile them in only in debug mode, but up to you | 13:15.55 |
| also, why only in linux? does gcc/clang/ld not support these options on other platforms? | 13:16.42 |
tor8 | avih: they're really jsut a leftover from mupdf's compile options (where they make more sense, since mupdf depending on configuration has a lot more code that can be left out) | 13:20.39 |
| why only linux? because we don't care enough about these small savings on other platforms, and it's not worth the potential trouble if it doesn't work. | 13:21.08 |
avih | i see | 13:21.24 |
tor8 | it's just a matter of not wanting to add untested options | 13:21.46 |
avih | yeah | 13:22.52 |
| works for me. thanks. when do you plan to push it to master? | 13:36.35 |
tor8 | avih: I can do that now. | 13:39.07 |
avih | seen it. thanks. | 13:39.41 |
hid | :/ | 14:20.39 |
| thanks tor8 :) | 14:20.45 |
| Forward 1 day (to 2018/06/16)>>> | |