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]
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]
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
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 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.