we don't build DSOs with -nostdlib. the resulting driver objects are linked against the system libc and ld.so, which will certainly break binary module portability. that's not cool. i hacked the imake rules to use -nostdlib - and dlloader objects work fine that way - but that's probably not the right word for it if $(CC) != gcc.
for sun cc the magic word seems to be -xnolib. i'll check icc in a bit. what other compilers would be affected here?
Created attachment 692 [details] [review] naive patch this patches Imake.rules to insert -nostdlib into the module target rules. This should work for gcc and icc users. the right thing to do would be to define a $(NOSTDLIB) for each compiler, but the compiler detection heuristics are non-obvious to me.
looks phat to mine eyes ... +1
Created attachment 1459 [details] [review] nostdlib-for-server-modules.patch slightly cleaner patch. this also adds the HasIntelC flag; icc users should set it, and anybody thinking of adding more icc-specific logic should key off HasIntelC.
applied to head, closing.
The proposed fix breaks loading modules on ia64 with: ./Xorg: error while loading shared libraries: /home/eich/fdo/build/exports/lib/modules/libint10.so: undefined symbol: __divsi3 This symbol lives in libc.
Created attachment 1798 [details] [review] ia64-dlloader-fix-1.patch ia64 is silly and puts various math symbols in libgcc rather than in libm. adding libgcc to the link line seems to work everywhere. don't know if this is appropriate for icc as well, so i'll assume no for the moment.
Yes, this works. Not pretty - but it should be OK. Ajax, are you going to commit this?
yes i will. need to sanity check it on x86 but it should be fine. give it an hour or so for the rebuild to finish. in theory we should be able to export that stuff from the server even on ia64, the way we do for pretty much every other platform. however i was utterly unable to get the server to put __divsi3 and friends in the exported symbol list, so i gave up and decided to link libgcc into the modules instead. this may or may not be a toolchain bug; i don't really feel like finding out. the only danger is if libgcc contains any syscalls and we end up emitting them directly into the module, which would break binary portability (even more). i doubt this will be a problem.
fixed in head.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.