Bug List: (This bug is not in your last search results)   Show last search results      Search page      Enter new bug
Bug#: 17608
Product:  
Component:  
Status: RESOLVED
Resolution: FIXED
Assigned To: Alan Modra <amodra@gmail.com>
Host:
Reported against  
Priority:  
Severity:  
Target Milestone:  
 
 
Target:
Reporter: Andreas Schwab <schwab@linux-m68k.org>
Add CC:
CC:
Remove selected CCs
Build:
URL:
Summary:
Keywords:
Known to work:
Known to fail:

Attachment Description Type Created Size Actions
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 17608 depends on: Show dependency tree
Show dependency graph
Bug 17608 blocks:

Additional Comments:






View Bug Activity   |   Format For Printing   |   Clone This Bug


Description:   Last confirmed: 2004-12-20 07:43 Opened: 2004-09-22 12:35
When linking with -profile then -lc_p is used instead of -lc, and the former is 
only available as a static library.  Thus this should be treated like a static 
link, and no shared libgcc should be linked in.  But when HAVE_LD_AS_NEEDED 
then -lgcc_s is also being linked in by default, causing a shared link that 
uses both libc_p and libc, and the resulting binary will crash.

------- Comment #1 From Andrew Pinski 2004-09-22 12:44 -------
This is a target problem....

------- Comment #2 From Mark Mitchell 2004-11-01 00:45 -------
Postponed until GCC 3.4.4.

------- Comment #3 From Alan Modra 2004-12-20 08:35 -------
I suspect that -profile ought to always imply -static.  For instance, you can
get the same crash by linking with -profile and -lm, because libm.so needs libc.so.

------- Comment #4 From Alan Modra 2004-12-22 02:44 -------
On investigating, I'm convinced this is a linker bug.  When linking we use:
-lgcc --as-needed -lgcc_s --no-as-needed -lc_p -lgcc --as-needed -lgcc_s
--no-as-needed.

During the first scan of libgcc_s.so, the linker finds no reason to mark
libgcc_s.so as needed, because no symbols in libgcc_s.so are referenced at that
point.  After linking libc_p.a, the second scan of libgcc_s.so does find
referenced symbols.  However, the linker sees that these symbols have already
been defined, thus the "new" definitions found in the second scan of libgcc_s.so
aren't used.  (If a symbol is defined in two shared libs, the one from the lib
first encountered by the linker is used.  As far as the linker is concerned the
first libgcc_s.so is a different shared lib from the second libgcc_s.so).  Thus
the linker decides that the second libgcc_s.so isn't needed, and so doesn't emit
a DT_NEEDED tag for libgcc_s.so.

With older glibc ld.so, this resulted in segfaults.  Current ld.so complains with
 Inconsistency detected by ld.so: dl-version.c: 230: _dl_check_map_versions:
Assertion `needed != ((void *)0)' failed!

------- Comment #5 From Alan Modra 2004-12-22 04:16 -------
Fixed by http://sources.redhat.com/ml/binutils/2004-12/msg00272.html
Since this was a linker problem, the proper solution would be to add a configure
test for a fixed linker and only enable USE_LD_AS_NEEDED when a good linker is
found.  However, that would disable this linker feature for the normal (ie. non
-profile) case, breaking cancellation.

Bug List: (This bug is not in your last search results)   Show last search results      Search page      Enter new bug