This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: GCC >= 3 problems
- From: "Maciej W. Rozycki" <macro at ds2 dot pg dot gda dot pl>
- To: "H . J . Lu" <hjl at lucon dot org>
- Cc: Steve Marotta <Stephen dot J dot Marotta at lmco dot com>, binutils at sources dot redhat dot com
- Date: Wed, 23 Jan 2002 20:48:37 +0100 (MET)
- Subject: Re: GCC >= 3 problems
- Organization: Technical University of Gdansk
On Wed, 23 Jan 2002, H . J . Lu wrote:
> > Well, good enough, to be called a hack or a workaround. How do you
> > assure the semantics of that hidden symbol provides what is expected by
> > the reference? In this specific case of atexit() it doesn't really matter
>
> That is how symbol versioning works. My patch just makes ld to follow
> the same rule as ld.so. You can only match the first version of the
> symbol with the unversioned reference.
If you want to follow ld.so in ld, you'd rather pull the object that
contains the symbol's definition from libc_nonshared.a and make it
available to the library from an executable. That's still a hack,
though, which is worse than the error that signals that something is
broken in a library now.
> > as the function is never invoked via this specific reference, but this
> > cannot be assumed in general.
> >
> > Note that the problem is not specific to libraries linked against glibc
> > 2.0.x -- several of glibc 2.2.x libraries do contain unresolved
> > (unversioned) atexit() references themselves if compiled by unfixed gcc
> > 2.95.x due to the buggy code in crtendS.o.
>
> Any shared libraries which call atexit will have undefined reference to
> atexit when linked against the older glibc, no matter what gcc is used.
But with a correct version attached as the symbol was known at the link
time.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +