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.
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
