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

[libtool-patches]

On Sun, Sep 09, 2001 at 05:30:49PM +0100, Gary V. Vaughan wrote:
> 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.

My results:
  1. GCC 2.95.3 without binutils on Solaris 8/SPARC fails (1.4.1)
  2. GCC 3.0.1 without binutils on Solaris 8/SPARC succeeds (1.4.1)

  3. GCC 2.95.3 with binutils on Solaris 2.6/SPARC succeeds (1.4.1)

  4. GCC 2.95.3 without binutils on Solaris 8/SPARC succeeds (1.3.5)

Because of #4, I say we reject the patch and find out why 1.3.5
succeeded.

-- 
albert chin (address@hidden)