http://sourceware.org/bugzilla/show_bug.cgi?id=12549
Summary: --as-needed should ignore weak references
Product: binutils
Version: 2.21
Status: NEW
Severity: normal
Priority: P2
Component: binutils
AssignedTo: unassig...@sources.redhat.com
ReportedBy: oss...@cendio.se
Created attachment 5276
--> http://sourceware.org/bugzilla/attachment.cgi?id=5276
binutils-2.20-weak-as-needed.patch
This is a bug entry for the following thread:
http://sourceware.org/ml/binutils/2010-04/msg00246.html
The basic problem is that on Solaris you easily get programs depending on
libgcc_s even though they do no really need any symbols from it. We considered
this a bug and fixed binutils to behave the way it does on Linux (glibc)
systems.
Initial message with the details:
I'm struggling with a bit of a problem when using the GNU toolchain
for a solaris target. This seems to be a fairly well known issue as
it's the basis for the USE_LD_AS_NEEDED thing in gcc. Unfortunately the
problem still isn't fully solved, so I was hoping to get some input and
hopefully progress this further.
The basic problem is:
- On non-glibc systems, crtbegin.o (from gcc) references
__register_frame_info. It does this always, even though it's only
really needed for exception handling. To alleviate this, the
references are marked as weak and the code is written to handle
these not getting resolved by the linker.
- When linking together a DSO, gcc will always add -lgcc_s and ld will
(correctly) add this as a dependency and will satisfy the
__register_frame_info references. Let's call this DSO libfoo.
- Linking a program does _not_ make gcc append -lgcc_s, so normally
you wouldn't get that unnecessary dependency. But linking a program
that uses libfoo makes ld follow the DT_NEEDED of it and put up
libgcc_s on the list of DSOs to check. Since the program will also
have crtbegin.o, with the weak __register_frame_info reference in
it, ld will add libgcc_s to the program as DT_NEEDED.
End result is that you have programs depending on libgcc_s even though
they do not use exception handling, complicating the deployment to
non-glibc systems.
This wasn't really acceptable to us, so we/I started looking at how to
make binutils and gcc do the correct thing. Since libgcc_s is needed in
some cases (like with g++), the key issue seem to be to make the
toolchain better respect the weak references. Two things are needed
here:
- gcc uses --as-needed on Linux systems around -lgcc_s, hoping that ld
would do the right thing<tm>. Unfortunately it didn't for non-glibc
systems, so these days only glibc 2.2+ systems get this flag. My
first step was reinstating this flag for every system that supported
it.
- The wrong thing<tm> that ld did was to consided libgcc_s as needed,
even though it only satisfied weak references. After a lot of
horrifying digging through binutils internals, I managed to make it
not consider DSOs with only weak references to it as needed.
Now this is now well behaved for this scenario, but is there some other
scenario that will break because of this? The documentation doesn't
mention how --as-needed and weak symbols interact, so it's currently
somewhat undefined. If not then I'd really appreciate if the patch
below could get merged.
There is a fixme in there about references from DSOs that I'm not sure
what's implied. I'm also not entirely clear on why ld's adding
DT_NEEDED to the program to satisfy unresolved symbols from a DSO.
Shouldn't it be up to the DSO to have whatever DT_NEEDED it requires to
fix up its dependencies?
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
