[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 5-gary-solaris-no-undefined.patch
From: |
Gary V. Vaughan |
Subject: |
Re: 5-gary-solaris-no-undefined.patch |
Date: |
Sun, 9 Sep 2001 17:30:49 +0100 |
User-agent: |
Mutt/1.3.21i |
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__/
- 5-gary-solaris-no-undefined.patch, Gary V. Vaughan, 2001/09/03
- Re: 5-gary-solaris-no-undefined.patch, Gary V. Vaughan, 2001/09/06
- Re: 5-gary-solaris-no-undefined.patch, libtool-patches, 2001/09/08
- Re: 5-gary-solaris-no-undefined.patch,
Gary V. Vaughan <=
- Re: 5-gary-solaris-no-undefined.patch, libtool-patches, 2001/09/09
- Re: 5-gary-solaris-no-undefined.patch, libtool-patches, 2001/09/09
- 12-gary-solaris-no-undefined.patch [Was Re: 5-gary-solaris-no-undefined.patch], Gary V. Vaughan, 2001/09/09
- Re: 12-gary-solaris-no-undefined.patch [Was Re: 5-gary-solaris-no-undefined.patch], libtool-patches, 2001/09/09
- Re: 12-gary-solaris-no-undefined.patch [Was Re: 5-gary-solaris-no-undefined.patch], Gary V. Vaughan, 2001/09/10