Re: 5-gary-solaris-no-undefined.patch

[Gary V. Vaughan]

On Sat, Sep 08, 2001 at 01:06:31AM -0500, address@hidden wrote:
> On Tue, Sep 04, 2001 at 12:43:11AM +0100, Gary V. Vaughan wrote:
> > Yuck!  This patch sucks... but it seems to work.  Alexandre, did you
> > have a good reason for your 04-11 patch?  If so we need to apply this
> > ugly patch, otherwise it might be better to revert to -z text?
> > 
> > Cheers,
> >     Gary.
> > 
> > Index: ChangeLog
> > from  Gary V. Vaughan  <address@hidden>
> >     * libtool.m4 (archive_cmds, archive_expsym_cmds) [solaris*]: Changing
> >     no_undefined_flag from `-z text' to `-z defs' (see entry below at
> >     2001-04-11  Alexandre Oliva  <address@hidden>) has a problem.
> >     when linking a shared library with gcc calling /usr/ccs/bin/ld (eg.
> >     the gcc supplied with Solaris 8 companion CD), using the flag
> >     -no-undefined, shared library linking will always fail because of
> >     the unresolved symbols from libgcc.a.  Consequently we have to
> >     provide a path to libgcc.a when linking shared libraries in
> >     conjunction with -no-undefined!
> 
> And what if you link with GCC. We built libtool 1.4.1 on Solaris
> (2.5.1-8) and didn't have problems but we were using the Sun C
> compiler. With GCC 2.95.3 I get (GCC *not* from Solaris Companion CD):
> 
> /bin/sh ./libtool --mode=link gcc  -O2 -mcpu=v8  -o libltdl.la -rpath
> /opt/TWWfsw/libtool14/lib -no-undefined -version-info 3:0:0 ltdl.lo
> -ldl 
> rm -fr .libs/libltdl.la .libs/libltdl.* .libs/libltdl.*
> /usr/ccs/bin/ld -G -z defs -h libltdl.so.3 -o .libs/libltdl.so.3.0.0
> ltdl.lo  -ldl -lc 
> Undefined                       first referenced
>  symbol                             in file
> __eprintf                           ltdl.lo
> ld: fatal: Symbol referencing errors. No output written to
> .libs/libltdl.so.3.0.0
> 
> I then tried:
>   $ /usr/ccs/bin/ld -G -z text -h libltdl.so.3 -o .libs/libltdl.so.3.0.0
>   ltdl.lo  -ldl -lc
> and didn't have problems. But, I see:
>   $ nm .libs/libltdl.so.3.0.0 | grep __eprintf
>   [153]   |         0|       0|NOTY |GLOB |0    |UNDEF  |__eprintf
> 
> Is this going to cause a problem if the Sun C compiler tries to link
> against a gcc-built shared library?

Yes it is :-(

The __eprintf symbol is resolved in libgcc.a, which is supposed to be
linked into the application that loads the library, and then resolved
using backlinks by the loader.  The patch I just reverted links a copy
of (non-PIC) libgcc.a into every library to resolve the symbol... bad
bad bad.

Interestingly, I installed gcc-3.0.1 and binutils (1.11?) from
sunfreeware.com to see if the problem persists.  This combination
works fine, so it seems to be a peculiarity of Sun's loader in
combination with gcc compiled objects.

Cheers,
        Gary.
-- 
  ())_. Gary V. Vaughan     gary@(oranda.demon.co.uk|gnu.org)
  ( '/  Research Scientist  http://www.oranda.demon.co.uk       ,_())____
  / )=  GNU Hacker          http://www.gnu.org/software/libtool  \'      `&
`(_~)_  Tech' Author        http://sources.redhat.com/autobook   =`---d__/