| | <<<Back 1 day (to 2018/09/23) | 20180924 |
| Robin_Watts | sebras, tor8: | 12:34.46 |
| | Should we be adding prefixes to our sublibraries? | 12:35.12 |
| | Paul has discovered that when he links mupdf against SO, he's getting problems because openjpeg is present both in SO and MuPDF. | 12:36.10 |
| | SO copes with this for jpeglib by prefixing every function name in jpeglib with something. | 12:36.59 |
| tor8 | build with USE_SYSTEM_OPENJPEG? | 12:37.26 |
| Robin_Watts | tor8: That assumes that both the system and us want the same version. | 12:37.49 |
| tor8 | adding prefixes to all thirdparty library symbols is going to be a royal PITA | 12:38.01 |
| Robin_Watts | SO isn't the only place where this is an issue. | 12:38.07 |
| | tor8: mmm. | 12:38.14 |
| tor8 | is there not some build flag to make all thirdparty library symbols non-visible when linking the mupdf lib? | 12:38.46 |
| Robin_Watts | We believe this problem has reared its head now because we link all the sublibs into libmupdf. | 12:39.24 |
| | I don't know of such a flag. | 12:39.34 |
| tor8 | it's mainly an issue because we've forked and modified certain thirdparty libraries and break when using certain system ones (like lcms2 vs lcms2-mt) | 12:39.47 |
| | Robin_Watts: if we link it as a dll, can we hide symbols then? | 12:40.22 |
| sebras | you can list what syms should be exported | 12:40.24 |
| Robin_Watts | I *could* do a configuration in the MuPDF project files to not link in OpenJPEG, and just use the version in SO, if that's kept up to date. | 12:40.28 |
| | sebras: In VS ? | 12:40.42 |
| sebras | in gcc, vs is your expert area. :) | 12:41.07 |
| Robin_Watts | tor8: SO uses static libs, I believe. | 12:41.10 |
| sebras | Robin_Watts: if SO does not keep openjpeg updated thats also an issue for wherever it otherwise needs j2k support... | 12:42.24 |
| Robin_Watts | Actually... SO only needs openjpeg for PDF. | 12:42.47 |
| sebras | right now we have very few patches on top of upstream. I hope we keep it that way. | 12:43.29 |
| Robin_Watts | yeah, fair enough. Forget I said anything for now. | 12:46.10 |
| tor8 | Robin_Watts: gladly :) this is a can of worms I'm loathe to open... | 12:49.07 |
| Robin_Watts | tor8: Sorry, cluster is misbehaving. I've restarted your job. | 14:59.50 |
| | tor8: I take it back, your build is genuinely failing. | 15:09.13 |
| moolc | tor8: think i've found at least one instance where memcpy was in fact "misbehaving" when i was fighting my aliasing battle | 15:31.43 |
| tor8 | Robin_Watts: yeah, it fails as expected... | 15:48.04 |
| | moolc: yeah... I'm still not entirely clear about the rules :( | 15:48.20 |
| Robin_Watts | tor8: My default position when I see a failure is "oops, I broke the cluster" :) | 15:48.32 |
| moolc | tor8: in case of memcpy the issue is exacerbated by the fact that compiler can (and sometimes does) produce utter shit :( | 16:00.00 |
| | Forward 1 day (to 2018/09/25)>>> | |
Log of #mupdf at irc.freenode.net.