[Bug ld/12548] New: anonymous version scripts no longer working with binutils 2.21
http://sourceware.org/bugzilla/show_bug.cgi?id=12548
Summary: anonymous version scripts no longer working with
binutils 2.21
Product: binutils
Version: 2.21
Status: NEW
Severity: normal
Priority: P2
Component: ld
AssignedTo: unassig...@sources.redhat.com
ReportedBy: oss...@cendio.se
I upgraded our build system from binutils 2.20 and gcc 4.4.3 to binutils 2.21
and gcc 4.5.2. This unfortunately broke support for anonymous version scripts.
Example from libjpeg-turbo:
sparc-sun-solaris2.10-gcc -shared .libs/jcapimin.o .libs/jcapistd.o
.libs/jccoefct.o .libs/jccolor.o .libs/jcdctmgr.o .libs/jchuff.o .libs/jcinit.o
.libs/jcmainct.o .libs/jcmarker.o .libs/jcmaster.o .libs/jcomapi.o
.libs/jcparam.o .libs/jcphuff.o .libs/jcprepct.o .libs/jcsample.o
.libs/jctrans.o .libs/jdapimin.o .libs/jdapistd.o .libs/jdatadst.o
.libs/jdatasrc.o .libs/jdcoefct.o .libs/jdcolor.o .libs/jddctmgr.o
.libs/jdhuff.o .libs/jdinput.o .libs/jdmainct.o .libs/jdmarker.o
.libs/jdmaster.o .libs/jdmerge.o .libs/jdphuff.o .libs/jdpostct.o
.libs/jdsample.o .libs/jdtrans.o .libs/jerror.o .libs/jfdctflt.o
.libs/jfdctfst.o .libs/jfdctint.o .libs/jidctflt.o .libs/jidctfst.o
.libs/jidctint.o .libs/jidctred.o .libs/jquant1.o .libs/jquant2.o
.libs/jutils.o .libs/jmemmgr.o .libs/jmemnobs.o .libs/jaricom.o .libs/jcarith.o
.libs/jdarith.o .libs/jsimd_none.o .libs/turbojpegl.o -lc
-Wl,--version-script -Wl,./turbojpeg-mapfile -Wl,-soname -Wl,libturbojpeg.so -o
.libs/libturbojpeg.so
/usr/lib/gcc/sparc-sun-solaris2.10/4.5.2/../../../../sparc-sun-solaris2.10/bin/ld:
anonymous version tag cannot be combined with other version tags
Contents of turbojpeg-mapfile:
{
global:
tjInitCompress;
tjCompress;
TJBUFSIZE;
tjInitDecompress;
tjDecompressHeader;
tjDecompressHeader2;
tjDecompress;
tjDestroy;
tjGetErrorStr;
local:
*;
};
The problem is specific to the Solaris/sparc backend. I have the same
binutils/gcc pair built and targeting i686, x86_64, win32 and win64 and I do
not get the problem there.
After some digging, I found that the problem is in ld/emultempl/solaris2.em,
which is part of the new Solaris 2 ABI stuff. It tries to add a new version
section for a bunch of symbols, which of course won't work when there is
already an anonymous section from the command line.
I'm not sure how to proceed here. I have to assume this version section is
being added for a reason, so I can't just remove it. Perhaps the entries need
to be merged with the existing section?
--
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
[Bug binutils/12549] New: --as-needed should ignore weak references
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. 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 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
[Bug gold/12525] gold SEGV linking libgcc_s.so.1 on Solaris 11/x86
http://sourceware.org/bugzilla/show_bug.cgi?id=12525 --- Comment #10 from Rainer Orth 2011-03-07 19:10:06 UTC --- > --- Comment #9 from Ian Lance Taylor 2011-03-04 > 19:08:43 UTC --- > output.cc does #include . gold is always compiled with > -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64. Those two facts together should > ensure that posix_fallocate is called with the right types. Can you suggest a > way that the gold source should be changed to fix this? Not yet, since this was just a guess based on the fact that truss showed impossibly large values for a couple of the fcntl struct flock64 members. I'll have to analyse this further. In the meantime, I've tried to disable posix_fallocate in config.h, thus using ftruncate (or rather ftruncate64) instead. This works (which suggests that my guess above may be wrong), but linking libgcc_s.so.1 fails again like this: gold-2.21: internal error in get_fde_pc, at /vol/gnu/src/binutils/binutils-2.21/gold/ehframe.cc:281 According to gcc/config/i386/sol2.h (ASM_PREFERRED_EH_DATA_FORMAT), Solaris 2/x86 uses datarel encoding, which isn't handled yet in gold/ehframe.cc (Eh_frame_hdr::get_fde_pc). Rainer -- 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
[Bug gold/12525] gold SEGV linking libgcc_s.so.1 on Solaris 11/x86
http://sourceware.org/bugzilla/show_bug.cgi?id=12525 --- Comment #11 from cvs-commit at gcc dot gnu.org 2011-03-07 22:51:43 UTC --- CVSROOT:/cvs/src Module name:src Changes by:i...@sourceware.org2011-03-07 22:51:40 Modified files: gold : ChangeLog options.h Log message: PR gold/12525 * options.h (class General_options): Add -dy and -dn. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/ChangeLog.diff?cvsroot=src&r1=1.700&r2=1.701 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/options.h.diff?cvsroot=src&r1=1.154&r2=1.155 -- 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
[Bug gold/12525] gold SEGV linking libgcc_s.so.1 on Solaris 11/x86
http://sourceware.org/bugzilla/show_bug.cgi?id=12525 --- Comment #12 from cvs-commit at gcc dot gnu.org 2011-03-07 22:51:54 UTC --- CVSROOT:/cvs/src Module name:src Branch: binutils-2_21-branch Changes by:i...@sourceware.org2011-03-07 22:51:50 Modified files: gold : ChangeLog options.h Log message: PR gold/12525 * options.h (class General_options): Add -dy and -dn. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/ChangeLog.diff?cvsroot=src&only_with_tag=binutils-2_21-branch&r1=1.664.2.18&r2=1.664.2.19 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/options.h.diff?cvsroot=src&only_with_tag=binutils-2_21-branch&r1=1.152&r2=1.152.2.1 -- 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
[Bug gold/12525] gold SEGV linking libgcc_s.so.1 on Solaris 11/x86
http://sourceware.org/bugzilla/show_bug.cgi?id=12525 --- Comment #13 from Ian Lance Taylor 2011-03-08 05:33:07 UTC --- Created attachment 5280 --> http://sourceware.org/bugzilla/attachment.cgi?id=5280 Possible patch Please try this patch to see if it fixes the assertion failure on get_fde_pc. The key will be whether the various exception tests in the testsuite pass. -- 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
