Re: Shared libraries build on Linux, not on Solaris 10 (gcc)

[Jason Curl]

Jason Curl wrote:
> Ralf Wildenhues wrote:
> > * Jason Curl wrote on Fri, Aug 17, 2007 at 12:05:44AM CEST:
> >  
> > > I've just switched over to using libtool instead of using static 
> > > libraries. I've installed autoconf-2.61, automake-1.10 and 
> > > libtool-1.5.24.
> > >
> > > The library builds fine under Linux, but won't link under Solaris 
> > > Sparc 2.10.
> > >     
> > [...]
> >  
> > > /opt/sfw/bin/gcc -shared  .libs/console.o .libs/file.o 
> > > .libs/output.o .libs/profile.o .libs/queue.o .libs/serial.o 
> > > .libs/strfunc.o .libs/tcpip.o .libs/ipcproto.o .libs/dbgmsg.o 
> > > .libs/appframework.o .libs/confopts.o .libs/netif.o 
> > > .libs/ether_ntoa.o .libs/getline.o .libs/strnlen.o .libs/timersub.o 
> > > .libs/timeradd.o  -lnsl -lsocket -lcurses -lc  -Wl,-soname 
> > > -Wl,liblogger.so.0 -o .libs/liblogger.so.0.0.0
> > > ld: warning: option -o appears more than once, first setting taken
> > > ld: fatal: file liblogger.so.0: open failed: No such file or directory
> > > ld: fatal: File processing errors. No output written to 
> > > .libs/liblogger.so.0.0.0
> > > collect2: ld returned 1 exit status
> > >     
> So I've been able to recreate the issue on Solaris 9. Compilation 
> works when I define (in a config.site file):
> CC=gcc
> LD=ld (/usr/ccs/bin/ld)
> AR=ar (/usr/ccs/bin/ar)
> RANLIB=ranlib (/usr/ccs/bin/ranlib)
>
> It sees GCC, but it sees the Solaris linker (and knows it's not GNU).
>
> But if I define LD=gld (/opt/sfw/bin) the GNU linker with GCC, then it 
> falls over with the error given above.
> > [...]
> >  
> > > So I play around a little with the options.
> > >
> > > 1. Remove -wl,-soname
> > >     
> >
> > That won't do good unless you also remove the argument to -soname, i.e.,
> > remove -Wl,liblogger.so.0.  Could you please try merging this, i.e.,
> > instead of   -Wl,-soname -Wl,liblogger.so.0
> >
> > use
> >   -Wl,-soname,liblogger.so.0
> >   
> Produces the same warning as before:
> ld: warning: option -o appears more than once, first setting taken
> ld: fatal: file liblogger.so.1: open failed: No such file or directory
> ld: fatal: File processing errors. No output written to 
> .libs/liblogger.so.1.0.0
> collect2: ld returned 1 exit status
> > and also add -v to see whether gcc happens to reorder arguments for ld?
> >
> >   
> Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.0/specs
> Configured with: ../configure --with-as=/usr/ccs/bin/as 
> --with-ld=/usr/ccs/bin/ld --disable-nls
> Thread model: posix
> gcc version 3.4.0
> /usr/local/libexec/gcc/sparc-sun-solaris2.9/3.4.0/collect2 -V -G -dy 
> -z text -Y P,/usr/ccs/lib:/usr/lib -Qy -o .libs/liblogger.so.1
> .0.0 /usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.0/crti.o 
> /usr/ccs/lib/values-Xa.o 
> /usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.0/crt
> begin.o -L/usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.0 -L/usr/ccs/bin 
> -L/usr/ccs/lib -L/usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.
> 0/../../.. .libs/console.o .libs/file.o .libs/output.o .libs/profile.o 
> .libs/queue.o .libs/serial.o .libs/strfunc.o .libs/tcpip.o .l
> ibs/ipcproto.o .libs/dbgmsg.o .libs/appframework.o .libs/confopts.o 
> .libs/netif.o .libs/getopt_long.o .libs/ether_ntoa.o .libs/getli
> ne.o .libs/strnlen.o .libs/timersub.o .libs/timeradd.o -lnsl -lsocket 
> -lc -soname liblogger.so.1 -lgcc_s -lgcc_s /usr/local/lib/gcc/
> sparc-sun-solaris2.9/3.4.0/crtend.o 
> /usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.0/crtn.o
> ld: Software Generation Utilities - Solaris Link Editors: 5.9-1.380
> ld: warning: option -o appears more than once, first setting taken
> ld: fatal: file liblogger.so.1: open failed: No such file or directory
> ld: fatal: File processing errors. No output written to 
> .libs/liblogger.so.1.0.0
> collect2: ld returned 1 exit status
>
> So it seems to me that the linker being configured is "gld" 
> (/opt/sfw/bin/gld) but GCC is using the system linker 
> (/usr/ccs/bin/ld) in anycase causing the error.
>
> Does this suggest a problem in the way that AC_PROG_LIBTOOL checks for 
> the linker? I had a quick look how to query the linker from GCC, but 
> it wasn't obvious.
There's no bug, except what I introduced. On Solaris when there is no 
GCC installed (or not in the path) and AC_PROG_LIBTOOL can't find LD 
from the compiler being used, it doesn't find LD. So I wrote a macro to 
find LD for me automatically on Solaris. Problem was, this macro was 
being run before AC_PROG_LIBTOOL and causing screwy things to happen. 
AC_PROG_LIBTOOL assumes it should be overridden and of course this error 
occurs.

It doesn't look like there's any easy way to specify in this case what 
LD to use within the 'configure' script. Sure I can enable the path, or 
specify a config.site script. But it's less hassle if it works out of 
the box on a standard installed Solaris box. Because AC_PROG_LIBTOOL 
looks for an 'ld'. It can't find it and dies. But if I specify one too 
early, on most systems it will fail.

What can I do? All I assume is I can update the PATH environment to 
point to LD. I'm trying my best to remove the need for a 'config.site' 
file for systems that have a pretty much standard install. I'm 
supporting FreeBSD6.1, Solaris 9, Solaris 10, Linux and Cygwin. I might 
have to copy the

As I said, I'm still coming to grips with libtool and I'm somewhat 
fumbling my way through (for those who haven't noticed).

The best I can think of is to duplicate what is there for AC_PROG_LD and 
use a hook (don't know how to do this) if LD is not found, then I can 
add extra searches and the whole libtool thing moves forward.

Cheers,
Jason.