LD_LIBRARY_PATH and GCC
Hello, Since migrating over to 'libtool' with automake to compile my packages, on Solaris 9 and 10 we're now getting the new error: ld.so.1: /home/user/myprog: fatal: libgcc_s.so.1: open failed: No such file or directory Killed Before using libtool and using convenience libraries only, this problem never occurred. I know I can solve this problem by defining the variable LD_LIBRARY_PATH, but the users never had to do this before. Now, when running with > ./configure --disable-shared it works as expected without the LD_LIBRARY_PATH. When static: > ldd myprog libnsl.so.1 => /usr/lib/libnsl.so.1 libsocket.so.1 =>/usr/lib/libsocket.so.1 libc.so.1 => /usr/lib/libc.so.1 libdl.so.1 =>/usr/lib/libdl.so.1 libmp.so.2 =>/usr/lib/libmp.so.2 /usr/platform/SUNW,Sun-Fire-V440/lib/libc_psr.so.1 When shared: > cd .libs > ldd myprog liblogger.so.1 =>(file not found) libnsl.so.1 => /usr/lib/libnsl.so.1 libsocket.so.1 =>/usr/lib/libsocket.so.1 libc.so.1 => /usr/lib/libc.so.1 libdl.so.1 =>/usr/lib/libdl.so.1 libmp.so.2 =>/usr/lib/libmp.so.2 /usr/platform/SUNW,Sun-Fire-V440/lib/libc_psr.so.1 > cd mylib/.libs > ldd mylib.so libnsl.so.1 => /usr/lib/libnsl.so.1 libsocket.so.1 =>/usr/lib/libsocket.so.1 libc.so.1 => /usr/lib/libc.so.1 libgcc_s.so.1 => (file not found) libdl.so.1 =>/usr/lib/libdl.so.1 libmp.so.2 =>/usr/lib/libmp.so.2 /usr/platform/SUNW,Sun-Fire-V440/lib/libc_psr.so.1 As the location of this library is specified by GCC, is there any way to automatically figure out where it is and tell the linker it should look there for the library? Or do people think this is a bad idea, and just a sideeffect of using shared libraries? Thanks, Jason. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Shared libraries build on Linux, not on Solaris 10 (gcc)
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. Cheers, Jason. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: LD_LIBRARY_PATH and GCC
On Tuesday 21 August 2007, Jason Curl wrote: > ld.so.1: /home/user/myprog: fatal: libgcc_s.so.1: open failed: No such > file or directory > Killed the distribution should be taking care of making sure libgcc_s.so.1 is readily available (or not needed). this is an internal gcc library and has no visibility at all from the libtool side of things. so i'd follow up with the people who made the toolchain you're using. -mike signature.asc Description: This is a digitally signed message part. ___ http://lists.gnu.org/mailman/listinfo/libtool
multilib dirs and ld.so
Hi, Albert pointed out to me yesterday that while, with 1.5.24 we now add the correct directories to sys_lib_search_path_spec, they do not get added to sys_lib_dlsearch_path_spec, resulting in libtool putting, for example, /usr/lib64 in RPATH. Red Hat have a patch for this, but it is specific to redhat: http://www.redhat.com/archives/fedora-extras-commits/2007-July/msg04567.html So, it looks like we need to revisit the methods of calculating sys_lib_dlsearch_path_spec in a distro independent fashion. The proposals so far: http://lists.gnu.org/archive/html/libtool/2007-06/msg00025.html The only worries I have with Olly's proposal are that it can be slow (but it is only run once at configure time, so hmm) and that I am not convinced that it outputs the directories in the order that ld.so searches. Peter ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: LD_LIBRARY_PATH and GCC
On Tue, 21 Aug 2007, Jason Curl wrote: Hello, Since migrating over to 'libtool' with automake to compile my packages, on Solaris 9 and 10 we're now getting the new error: ld.so.1: /home/user/myprog: fatal: libgcc_s.so.1: open failed: No such file or directory Killed [ stuff removed ] As the location of this library is specified by GCC, is there any way to automatically figure out where it is and tell the linker it should look there for the library? Under Solaris, I make GCC's libgcc_s.so.1 available in a shared area (e.g. /usr/local/lib) and tell the system to look there using 'crle'. The problem is therefore resolved, and the program itself is not dependent on the location of libgcc_s.so.1. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Shared libraries build on Linux, not on Solaris 10 (gcc)
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 t
Re: Creating ONLY static libraries
Omri Azencot wrote: Hello I am using libtool 1.5.23 during the building process, I am also using autoconf(2.61) to create the configure file. in configure.ac I used the macro AC_DISABLE_SHARED, and in the log I got the following line: checking whether to build shared libraries... no but, after "make install" the package did installed in the installation folder files of the type *.la *.dll.a. My goal is to create only static libraries of this module, am I missing something ? If you don't need to have the libraries installed for a convenience library, use "noinst_*". See: http://www.gnu.org/software/automake/manual/automake.html#A-Library Similarly for libtool: http://www.gnu.org/software/libtool/manual.html#Static-libraries The answer from Mike is correct, they're static libraries that other programs may link to if wanted. How do you plan to use this library? ___ http://lists.gnu.org/mailman/listinfo/libtool
AC_PROG_LIBTOOL sets CFLAGS
according to my reading of info nodes: (libtool) AC_PROG_LIBTOOL (automake) Flag Variables Ordering the shell variable CFLAGS should have no value after AC_PROG_LIBTOOL. i.e., i should expect the configure.ac fragment: echo "CFLAGS: $CFLAGS" AC_PROG_LIBTOOL echo "CFLAGS: $CFLAGS" to create a configure that outputs "CFLAGS: " both before and after whatever code is generated as the expansion of AC_PROG_LIBTOOL. is my interpretation correct? presently, i see that before, CFLAGS is indeed empty, while after, it has the value "-g -O2" (compiler is gcc), using libtool 1.5.22, autoconf 2.60, automake 1.9.6. to see for yourself, try: $ mkdir /tmp/z $ cd /tmp/z $ cat > configure.ac
Re: AC_PROG_LIBTOOL sets CFLAGS
On Tue, 2007-08-21 at 21:49 +0200, Thien-Thi Nguyen wrote: > according to my reading of info nodes: > > (libtool) AC_PROG_LIBTOOL > (automake) Flag Variables Ordering > > the shell variable CFLAGS should have no value after AC_PROG_LIBTOOL. > i.e., i should expect the configure.ac fragment: > > echo "CFLAGS: $CFLAGS" > AC_PROG_LIBTOOL > echo "CFLAGS: $CFLAGS" > > to create a configure that outputs "CFLAGS: " both before and after > whatever code is generated as the expansion of AC_PROG_LIBTOOL. > > is my interpretation correct? presently, i see that before, CFLAGS is > indeed empty, while after, it has the value "-g -O2" (compiler is gcc), > using libtool 1.5.22, autoconf 2.60, automake 1.9.6. > > to see for yourself, try: > > $ mkdir /tmp/z > $ cd /tmp/z > $ cat > configure.ac < AC_INIT([foo],[0],[ttn]) > AM_INIT_AUTOMAKE > echo "CFLAGS: $CFLAGS" > AC_PROG_LIBTOOL > echo "CFLAGS: $CFLAGS" > AC_CONFIG_FILES([Makefile]) > AC_OUTPUT > EOF > $ touch NEWS README AUTHORS ChangeLog Makefile.am > $ autoreconf -is > $ ./configure > > i suppose the "-g -O2" is good to have *somewhere*, which would lead, > presuming the observed behavior is undesirable and will be fixed in some > future libtool, to the follow on question: if not CFLAGS, then where? > AC_PROG_LIBTOOL calls AC_PROG_CC which sets default CFLAGS (but only if they are not already set). Peter ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Creating ONLY static libraries
On 8/21/07, Jason Curl <[EMAIL PROTECTED]> wrote: > > >If you don't need to have the libraries installed for a convenience > >library, use "noinst_*". See: > >http://www.gnu.org/software/automake/manual/automake.html#A-Library > > > >Similarly for libtool: > >http://www.gnu.org/software/libtool/manual.html#Static-libraries > > > >The answer from Mike is correct, they're static libraries that other > >programs may link to if wanted. > > > >How do you plan to use this library? I am trying to build some program under Cygwin/X and it seemed that there is some sort of problem with linking to one of the libraries (*.la) which were made during the build process. anyway after I added "--disable-shared" to configure, the build process went O.K. and I didnt get no ld error. I am still not sure if the problem is from Libtool or Cygwin/X (my guess is Cygwin/X) , but for now I am quite satisfied with the static libraries as is. thank you all for your help ! Azencot Omri ___ http://lists.gnu.org/mailman/listinfo/libtool
