Log of #ghostscript at irc.freenode.net.

Search:
 <<<Back 1 day (to 2019/03/25)20190326 
chrisl Redfoxmoon: I don't see any reason why it should make a difference what the binary format is, but in any case, just don't use it: it has no advantage over the regular X11 gs devices07:40.12 
Foxie well, the jpeg issue yesterday is completely resolved, turns out it was a pathing issue09:00.47 
  The X11 module on the other hand is missing a whole heap of objects when linking, what's up with that?09:01.07 
kens Presumably you're building with X and you don't have the x development stuff ?09:02.15 
chrisl Foxie: well, again, it works for me, and a *lot* of linux distributions so..... I don't know.09:02.27 
Foxie I do09:02.32 
  My target uses PE, not ELF:-)09:02.47 
  If any symbols are missing at link time, it fails09:03.39 
chrisl So, no DLLs then09:03.54 
Foxie Sure you can use dynamic link libraries, but you need to explicitly link with them09:04.41 
  Say X11.so needs symbols present in gsparam.c which is not pulled in when it's built09:05.07 
  that's one example I can think of right now...09:05.15 
chrisl So, there's no support for dlopen() etc09:05.41 
Foxie dlopen(3) and friends are supported09:21.12 
chrisl Well, I can see no reason for the dynamic devices not to work....09:22.37 
Foxie Okay let me re-phrase, the file gsparam.c, is that supported to be part of libgs?09:24.38 
chrisl Yes09:26.20 
Foxie just trying to understand how to fix this properly09:26.25 
  ah, I see09:26.26 
chrisl You could just leave the dynamic devices out09:27.12 
Foxie I just disabled X11 support, and it built fine09:27.27 
  I guess if you were to build gs on linux with -no-undefined it wouldn't work09:28.08 
chrisl The reason for the X11.o stuff is so distros can do ghostscript and ghostscript-nox packages without building two complete executables09:28.48 
Foxie Makes sense09:30.39 
chrisl Although, gsparam.c doesn't seem to be in the mix, there....09:31.19 
  Foxie: Also, I just reread what you said and X11.o should only be "linked" at run time09:33.44 
Foxie well yes, ELF allows runtime linkage09:35.12 
chrisl So does PE09:36.15 
  We, in fact, use that capability in our Windows binary09:36.53 
Foxie PE enforces -no-undefined, of course dynamic libraries can still be loaded at runtime09:42.35 
  but all dependencies must be specified at compile time09:43.34 
chrisl Strange, the LoadLibrary docs seem to leave out that detail. Kind of buggers up using DLLs as optional plugins - which is strange given so many applications support that09:55.03 
Foxie not at all!10:02.08 
  If you have a base dll and a plugin system, you just link the plugin dlls with the base dll at compile time10:02.44 
  then LoadLibrary them if you want to use them10:02.49 
chrisl So... dlopen is supported, but has different requirements?10:04.37 
Foxie If you attempt to dlopen(3) a library that has unresolved dependencies it'll fail just like on linux10:05.29 
chrisl Ah, I bet that the linker doesn't support the -shared option10:09.51 
  Or has different requirements compared to "real" Unix systems10:12.15 
  For GNU ld at least: -shared "This is currently only supported on ELF, XCOFF and SunOS platforms"10:13.12 
Foxie :-)10:17.01 
  If you want you can come to #midipix / midipix.org10:17.21 
  we've got at least two windows experts:-)10:17.32 
chrisl Thanks, but I have enough on my plate - I'll stick to Linux. You might suggest that if it's not supported, passing -shared to the linker should cause a specific error. That would have saved us both time10:19.11 
Foxie -shared is supported10:20.37 
  but alright, I'll see if I can fix the linking issue in a clean way10:21.13 
  Can I submit build system patches here?10:21.29 
chrisl bugs.ghostscript.com10:21.45 
  Foxie: Maybe add --allow-shlib-undefined to the X11.o build rule?10:31.12 
 Forward 1 day (to 2019/03/27)>>> 
ghostscript.com #mupdf
Search: