[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 5-gary-solaris-no-undefined.patch
From: |
libtool-patches |
Subject: |
Re: 5-gary-solaris-no-undefined.patch |
Date: |
Sun, 9 Sep 2001 12:41:48 -0500 |
User-agent: |
Mutt/1.2.5i |
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)