Re: GCC >= 3 problems

["Maciej W. Rozycki" <macro at ds2 dot pg dot gda dot pl>]

On Wed, 23 Jan 2002, H . J . Lu wrote:

> >  You have to recompile it because it bogusly references a symbol that was
> > unknown at the library's link time and therefore has to be provided by an
> > executable.  If an executable does not provide it, linking obviously
> > fails.  IOW, the library was built incorrectly and thus needs a rebuild. 
> 
> Here is the related thread:
> 
> http://sources.redhat.com/ml/binutils/2001-05/msg00124.html
> 
> My current patch is different from it. The Linux binutils will do the
> similar thing as the ld.so. Here are the ChangeLog entries:
> 
>         * elf-bfd.h (elf_link_loaded_list): New structure.
>         (elf_link_hash_table): Add "loaded".
> 
>         * elf.c (_bfd_elf_link_hash_table_init): Initialize the
>          "loaded" field to NULL.
> 
>         * elflink.h (elf_link_check_versioned_symbol): New function.
>         Return true if there is one hidden definition for the undefined
>         symbol.
> 
>         * elflink.h (elf_link_output_extsym): For undefined symbol in
>         DSO from DT_NEEDED, Call elf_link_check_versioned_symbol to
>         check if there is one hidden definition.

 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
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. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +