Bug 1054 - dlloader modules are linked against the system libraries
Summary: dlloader modules are linked against the system libraries
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/DDX/Xorg/dlloader (show other bugs)
Version: git
Hardware: x86 (IA32) Linux (All)
: high normal
Assignee: Adam Jackson
QA Contact:
Depends on:
Blocks: 400
  Show dependency treegraph
Reported: 2004-08-11 23:08 UTC by Adam Jackson
Modified: 2005-01-31 19:27 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:

naive patch (766 bytes, patch)
2004-08-20 14:48 UTC, Adam Jackson
no flags Details | Splinter Review
nostdlib-for-server-modules.patch (1.58 KB, patch)
2004-12-03 14:17 UTC, Adam Jackson
no flags Details | Splinter Review
ia64-dlloader-fix-1.patch (1.48 KB, patch)
2005-01-31 08:29 UTC, Adam Jackson
no flags Details | Splinter Review

Description Adam Jackson 2004-08-11 23:08:24 UTC
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.
Comment 1 Adam Jackson 2004-08-12 13:46:21 UTC
for sun cc the magic word seems to be -xnolib.  i'll check icc in a bit.  what
other compilers would be affected here?
Comment 2 Adam Jackson 2004-08-20 14:48:24 UTC
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.
Comment 3 Daniel Stone 2004-11-12 00:33:10 UTC
looks phat to mine eyes ... +1
Comment 4 Adam Jackson 2004-12-03 14:17:35 UTC
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
Comment 5 Adam Jackson 2004-12-12 13:01:10 UTC
applied to head, closing.
Comment 6 Egbert Eich 2005-01-31 07:14:55 UTC
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.
Comment 7 Adam Jackson 2005-01-31 08:29:07 UTC
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.
Comment 8 Egbert Eich 2005-01-31 10:44:50 UTC
Yes, this works. Not pretty - but it should be OK.
Ajax, are you going to commit this?
Comment 9 Adam Jackson 2005-01-31 11:16:33 UTC
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.
Comment 10 Adam Jackson 2005-02-01 14:27:28 UTC
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.