GCC >= 3 problems

[Maciej W. Rozycki]

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        +