Re: build check in AIX 5.2 / 5.3 / 6.1
Hello, Ralf Wildenhues wrote: Hello Rainer, * Rainer Tammer wrote on Wed, Jan 09, 2008 at 12:25:03PM CET: I have checked the following libtool versions on several AIX versions: 1. branch-1.5-20080108-cvs on AIX 5.2, 5.3, 6.1 result: AIX 5.2 / branch-1.5 / OK AIX 5.3 / branch-1.5 / OK AIX 6.1 / branch-1.5 / OK 2. HEAD-20080108-cvs on AIX 5.3, 6.1 result: AIX 5.3 / HEAD / testsuite OK, FAIL: tests/mdemo-exec.test (3 times) AIX 6.1 / HEAD / testsuite OK, FAIL: tests/mdemo-exec.test (3 times) The detailed test results are in the attached archive. All test were conducted with IBM C/C++ compilers. And all tests were done with runtimelinking enabled (-brtl). It'd be cool if we could even get things to work smoothly without, but having it working with it is already good. I think IBM recommends the rtl method... I attach a short paper from IBM to this mail - linking102. The baseline from this paper is: * build shared modules with -G or -brtl -bnortllib -bnosymbolic -berok -bM:SRE (which is the same) * build the app with -brtl So we basically have only one bug left with XL/runtimelinking (the mdemo-exec one). If you like me to perforce some tests with gcc then I can try that too.. Yes, that would be great. The systems I test on currently don't have g++ or gfortran (or gcj) installed, so if you could test ./configure CC=gcc CXX=g++ FC=gfortran F77=gfortran I can check gcc/g++. Unfortunately I do not have Fortran installed. Maybe I can try a build test with IBM xlf 5.x (very old version) but this is a bit complicated as I only have very limited access to this machine. (with LDFLAGS=-Wl,-brtl added, and maybe even without) that would help a lot. Cheers, and many thanks for your work! Ralf Bye Rainer linking102-a4.pdf Description: Adobe PDF document ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
libtool ChangeLog f77demo/cprogram.c f77demo/fo... [branch-1-5]
CVSROOT:/cvsroot/libtool Module name:libtool Branch: branch-1-5 Changes by: Ralf Wildenhues rwild 08/01/09 19:54:19 Modified files: . : ChangeLog f77demo: cprogram.c fooc.c mdemo : main.c Log message: * mdemo/main.c: Include string.h, for strrchr. Report by Rainer Tammer. * f77demo/cprogram.c: Include stdio.h, for printf. * f77demo/fooc.c: Likewise. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/libtool/ChangeLog?cvsroot=libtoolonly_with_tag=branch-1-5r1=1.1220.2.478r2=1.1220.2.479 http://cvs.savannah.gnu.org/viewcvs/libtool/f77demo/cprogram.c?cvsroot=libtoolonly_with_tag=branch-1-5r1=1.1.2.1r2=1.1.2.2 http://cvs.savannah.gnu.org/viewcvs/libtool/f77demo/fooc.c?cvsroot=libtoolonly_with_tag=branch-1-5r1=1.1r2=1.1.2.1 http://cvs.savannah.gnu.org/viewcvs/libtool/mdemo/main.c?cvsroot=libtoolonly_with_tag=branch-1-5r1=1.19.4.2r2=1.19.4.3 ___ Libtool-commit mailing list Libtool-commit@gnu.org http://lists.gnu.org/mailman/listinfo/libtool-commit
Re: build check in AIX 5.2 / 5.3 / 6.1
* Rainer Tammer wrote on Wed, Jan 09, 2008 at 12:25:03PM CET:
[ branch-1.5-20080108-cvs/check.log ]
creating libmlib.la (cd .libs rm -f libmlib.la ln -s ../libmlib.la
libmlib.la) cc_r -qlanglvl=extc89 -DPACKAGE_NAME=\mdemo\
-DPACKAGE_TARNAME=\mdemo\ -DPACKAGE_VERSION=\0.1\
-DPACKAGE_STRING=\mdemo\ 0.1\ -DPACKAGE_BUGREPORT=\[EMAIL PROTECTED]
-DPACKAGE=\mdemo\ -DVERSION=\0.1\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
-DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1
-DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1
-DHAVE_DLFCN_H=1 -DHAVE_MATH_H=1 -I. -I./../libltdl-g -c main.c
main.c, line 195.7: 1506-068 (W) Operation between types char* and int
is not allowed.
While we're at it, let's fix that buglet, and a couple of other ones I
found. Applied to branch-1-5 (HEAD is fixed already).
Cheers,
Ralf
2008-01-09 Ralf Wildenhues [EMAIL PROTECTED]
* mdemo/main.c: Include string.h, for strrchr.
Report by Rainer Tammer.
* f77demo/cprogram.c: Include stdio.h, for printf.
* f77demo/fooc.c: Likewise.
Index: f77demo/cprogram.c
===
RCS file: /cvsroot/libtool/libtool/f77demo/Attic/cprogram.c,v
retrieving revision 1.1.2.1
diff -u -r1.1.2.1 cprogram.c
--- f77demo/cprogram.c 22 Apr 2005 09:05:43 - 1.1.2.1
+++ f77demo/cprogram.c 9 Jan 2008 19:53:22 -
@@ -15,6 +15,7 @@
USA. */
#include foo.h
+#include stdio.h
int
main(int argc, char **argv)
Index: f77demo/fooc.c
===
RCS file: /cvsroot/libtool/libtool/f77demo/Attic/fooc.c,v
retrieving revision 1.1
diff -u -r1.1 fooc.c
--- f77demo/fooc.c 31 Jul 2002 20:15:27 - 1.1
+++ f77demo/fooc.c 9 Jan 2008 19:53:22 -
@@ -1,4 +1,5 @@
#include foo.h
+#include stdio.h
int csub(int arg)
Index: mdemo/main.c
===
RCS file: /cvsroot/libtool/libtool/mdemo/Attic/main.c,v
retrieving revision 1.19.4.2
diff -u -r1.19.4.2 main.c
--- mdemo/main.c24 Jul 2007 05:11:13 - 1.19.4.2
+++ mdemo/main.c9 Jan 2008 19:53:22 -
@@ -1,5 +1,5 @@
/* main.c -- mdemo test program
- Copyright (C) 1998-2000, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1998-2000, 2007, 2008 Free Software Foundation, Inc.
Originally by Thomas Tanner [EMAIL PROTECTED]
This file is part of GNU Libtool.
@@ -21,10 +21,12 @@
#include foo.h
#include ltdl.h
#include stdio.h
+#include string.h
int
test_dl (filename, test_ext)
char *filename;
+ int test_ext;
{
lt_dlhandle handle;
const lt_dlinfo *info;
Re: darwin patches for HEAD
Ralf Wildenhues wrote: Drop support for xlc, it is probably broken. Do you know it is broken, or just guess? Or does this patch just intentionally break it. This would be a regression over branch-1-5. (I'm not saying that I have a problem with the removal, your call.) I think it is broken, but do not know, nor care. I realize that it is a regression over 1.5, but I have never gotten any feedback on xlc support, and do not believe that anyone cares. * tests/template.at [darwin]: Skip this test, I can not find a way to make it work on darwin9 with Xcode-3.0. * NEWS: Note the dropping of xlc support. + _LT_DECL([], [NMEDIT], [1], +[]) Can you provide a short description of these tools in the _LT_DECL? By looking at the names alone, I wouldn't even think they are connected with darwin at all, nor really know what they do. Ok I haven't tried any LT_MULTI_MODULE runs yet (should I try combining that with MACOSX_DEPLOYMENT_TARGET also?). No. sigh. I will have to add a test that the output has dwarf debugging symbols before putting dsymutil into the archive_cmds. Thanks for catching this. Peter -- Peter O'Gorman http://pogma.com
Re: ld --rpath problem using libtool
Hi Ralf, On Wednesday 09 January 2008 07:48, Ralf Wildenhues wrote: I think the issue is this: libtool doesn't add a run path to /opt/etherlab/lib because it thinks the runtime linker will already search that by default. Your --config output shows that it is listed ... I'm wondering, if it's listed there (could you please confirm that?), why doesn't the runtime linker find it then in your case? I'm most impressed how quickly you put the finger on the wound :). That was the mistake! Before discovering how libtool helps me with the work, I used ld.so.conf - and it has been lying there ever since. Thanks a lot - Richard ___ http://lists.gnu.org/mailman/listinfo/libtool
libtool problem when cross compiling net-snmp
Hi, I'm trying to cross compile net-snmp but have run into a libtool problem. I'm using libtool 1.5.24 together with net-snmp 5.4.1. I've tracked down the problem to archive_cmds in libtool. The $deplibs parameter indicates -L/usr/lib instead of -L/home/goranh/src/etrax/target/crisv32-axis-linux-gnu/usr/lib. Has anyone experinced this problem or can point me where to find a solution to this problem? Regards, Goran libtool: install: warning: relinking `libnetsnmpagent.la' (cd /usr/local/src/etrax/apps/ucd-snmp/net-snmp-5.4/src/agent; /bin/sh ../libtool --mode=relink gcc-cris -isystem /home/goranh/src/etrax/target/crisv32-axis-linux-gnu/include -isystem /home/goranh/src/etrax/target/crisv32-axis-linux-gnu/usr/include -mlinux -march=v32 -Wall -Os -g -I/home/goranh/src/etrax/target/crisv32-axis-linux-gnu/usr/include -Ulinux -Dlinux=linux -rpath /usr/lib -version-info 16:0:1 -o libnetsnmpagent.la snmp_agent.lo snmp_vars.lo agent_read_config.lo agent_registry.lo agent_index.lo agent_trap.lo kernel.lo agent_handler.lo mibgroup/utilities/execute.lo mibgroup/mibII/vacm_conf.lo mibgroup/snmpv3/usmConf.lo ../snmplib/libnetsnmp.la -L/home/goranh/src/etrax/target/crisv32-axis-linux-gnu/lib -L/home/goranh/src/etraxtarget/crisv32-axis-linux-gnu/lib -L/home/goranh/src/etrax/target/crisv32-axis-linux-gnu/usr/lib -L/home/goranh/src/etrax/target/crisv32-axis-linux-gnu/usr/lib -inst-prefix-dir /home/goranh/src/etrax/target/crisv32-axis-linux-gnu) gcc-cris -isystem /home/goranh/src/etrax/target/crisv32-axis-linux-gnu/include -isystem /home/goranh/src/etrax/target/crisv32-axis-linux-gnu/usr/include -mlinux -march=v32 -shared .libs/snmp_agent.o .libs/snmp_vars.o .libs/agent_read_config.o .libs/agent_registry.o .libs/agent_index.o .libs/agent_trap.o .libs/kernel.o .libs/agent_handler.o mibgroup/utilities/.libs/execute.o mibgroup/mibII/.libs/vacm_conf.o mibgroup/snmpv3/.libs/usmConf.o -L/home/goranh/src/etrax/target/crisv32-axis-linux-gnu/usr/lib -L/usr/lib -lnetsnmp -L/home/goranh/src/etrax/target/crisv32-axis-linux-gnu/lib -mlinux -march=v32 -Wl,-soname -Wl,libnetsnmpagent.so.15 -o .libs/libnetsnmpagent.so.15.1.0 /usr/local/cris/lib/gcc-lib/crisv32-axis-linux-gnu/3.2.1/../../../../crisv32-axis-linux-gnu/bin/ld:/usr/lib/libc.so: file format not recognized; treating as linker script /usr/local/cris/lib/gcc-lib/crisv32-axis-linux-gnu/3.2.1/../../../../crisv32-axis-linux-gnu/bin/ld:/usr/lib/libc.so:5: parse error collect2: ld returned 1 exit status libtool: install: error: relink `libnetsnmpagent.la' with the above command before installing it installing libnetsnmpagent.la in /home/goranh/src/etrax/target/crisv32-axis-linux-gnu/usr/lib PATH=$PATH:/sbin ldconfig -n /usr/lib The wrapper file for net-snmp i'm using looks like this: AXIS_USABLE_LIBS = UCLIBC GLIBC include $(AXIS_TOP_DIR)/tools/build/Rules.axis SRCDIR= src LDFLAGS += -L$(prefix)/usr/lib CPPFLAGS += -I$(prefix)/usr/include CFLAGS := `echo $(CFLAGS)|sed 's/-Wshadow//'` CFLAGS += -I$(prefix)/usr/include INSTMODE = 0755 INSTOWNER = root INSTGROUP = root INST_PROG = $(AXIS_TOP_DIR)/tools/build/bin/$(shell echo $(INSTALL)|sed 's/^ *//') test: @echo CC: $(CC) @echo CFLAGS: $(CFLAGS) @echo LD: $(LD) @echo LDFLAGS: $(LDFLAGS) @echo INSTALL: $(INSTALL) @echo INST_PROG: $(INST_PROG) @echo RANLIB: $(RANLIB) $(SRCDIR)/Makefile: cd $(SRCDIR) \ ./configure \ --target=$(AXIS_BUILDTYPE) \ --host=$(AXIS_BUILDTYPE) \ --prefix=/usr \ --with-ar=$(AR) \ --with-cc=$(CC) \ --with-cflags=$(CFLAGS) \ --with-ld=$(LD) \ --with-ldflags=$(LDFLAGS) \ --with-install-prefix=$(prefix) \ --disable-applications \ --disable-debugging \ --disable-embedded-perl \ --disable-manuals \ --disable-mibs \ --disable-mib-loading \ --disable-scripts \ --disable-snmpv1 \ --enable-mini-agent \ --enable-reentrant \ --enable-shared \ --with-default-snmp-version=3 \ --with-endianness=little \ --with-logfile=/var/log/snmpd.log \ --with-openssl=$(prefix) \ --with-mib-modules=mibII ip-mib tcp-mib \ --with-persistent-directory=/var/net-snmp \ --without-perl-modules \ --without-root-access \ --without-rpm \ STRIP=$(STRIP) \ INSTALL=$(INST_PROG) RM=$(RM) ___ http://lists.gnu.org/mailman/listinfo/libtool
RE: mingw install directory for shared lib
On Wed, 9 Jan 2008, Duft Markus wrote: Bob Friesenhahn wrote: On Tue, 8 Jan 2008, Ralf Wildenhues wrote: General question before fixing this: on w32, should even plugins have their DLLs go to $bindir? Yes, i'd agree to this... ;o) If you try to load a library by yourself, you will have to know what you're doing. If the DLL is linked to the executable, you have no (easy) way to influence what is done by the loader... Modules should not be linked with an executable. That would surely be bad design and should not be supported. There should be no need to load a module by yourself since libtool offers libltdl which does it for you by requesting to load the associated .la file. Regardless, loading modules directly is trivially easy under Windows. Of course there may still be problems if there are dependencies between plugins, that are installed in different directories, since loading one plugin will load all libraries this dll is linked to. If those are plugins themselves, they will have to be in PATH to be found (or in the same directory, etc.). The easiest solution is using parity ;) but thats self-advertisement again, sorry... There should be no dependencies between plugins. That would surely be bad design and should not be supported. Libtool should be supporting portable behavior. If the user does not desire to implement portable behavior, then there is little value to using libtool or libltdl. The portable definition for windows should be: library - Executables (usually) link directly with libraries and when the library is a DLL it should be installed in the executable search path, and (ideally) be in the same 'bin' directory as the dependent executables. module - Modules are only loaded via an explicit loading mechanism (e.g. Windows LoadLibrary() or libltdl. Modules may depend on libraries (see above) but should not depend on other modules. Since modules are explicitly loaded, they may be installed in an application-specific lib directory (just like for Unix). 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: mingw install directory for shared lib
On Wed, 9 Jan 2008, Bob Rossi wrote: There should be no dependencies between plugins. I don't know. That sentence goes a little to far really. When pcre is built on windows, it creates two dlls. The first is the regex dll which supports the POSIX regex functionality. The second is a C++ interface to the first library. Therefore, the C++ interface depends on the regex library. Do you think that's bad? You are saying that POSIX regular expressions is implemented as a loadable module? That is odd. Normally one would find such things in a library. Regardless, if care is taken, a module can be used to implement such functionality without linkage dependency. There are problems if linkage dependencies are on a module: 1) If module is not available then program (or subsequent modules) do not run. 2) OS-dependent search/loading procedures are used. 3) Modules need to be loaded in a particular order or else program fails with an ugly run-time error due to an unresolved symbol (e.g. Microsoft Windows dialog box) or otherwise mis-behaves. 4) Module namespace needs to be exported globally (not the libltdl default) so that subsequently-loaded modules may use its symbols. This is not portable and may result in duplicate symbol issues. Such modules can never be safely unloaded again. Where did you get this definition? I don't know, maybe I'm wrong, I don't have a lot of experience in this area. The pcre behavior comes I just made it up. 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: mingw install directory for shared lib
On Tue, Jan 08, 2008 at 11:29:15PM +0200, Tor Lillqvist wrote: Shouldn't plug-in -type shared libraries be built with the -module -avoid-version libtool flags? I think with those flags, such libtool-built DLLs get installed in the libdir of the Makefile in question, not libdir/../bin like normal DLLs. I previously had, libfoo_la_LDFLAGS = -no-undefined When I change it to this, libfoo_la_LDFLAGS = -no-undefined -module or this, libfoo_la_LDFLAGS = -no-undefined -module -avoid-version Then the dll doesn't seem to get installed at all. I really don't understand this at all. Any ideas? Bob Rossi ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool problem when cross compiling net-snmp
Hello Göran, * Göran Hillebrink wrote on Wed, Jan 09, 2008 at 04:27:27PM CET: I'm trying to cross compile net-snmp but have run into a libtool problem. I'm using libtool 1.5.24 together with net-snmp 5.4.1. I've tracked down the problem to archive_cmds in libtool. The $deplibs parameter indicates -L/usr/lib instead of -L/home/goranh/src/etrax/target/crisv32-axis-linux-gnu/usr/lib. Not sure whether I can help you, but could you please run this command manually with --debug added right after `../libtool': (cd /usr/local/src/etrax/apps/ucd-snmp/net-snmp-5.4/src/agent; /bin/sh ../libtool --mode=relink gcc-cris -isystem /home/goranh/src/etrax/target/crisv32-axis-linux-gnu/include -isystem /home/goranh/src/etrax/target/crisv32-axis-linux-gnu/usr/include -mlinux -march=v32 -Wall -Os -g -I/home/goranh/src/etrax/target/crisv32-axis-linux-gnu/usr/include -Ulinux -Dlinux=linux -rpath /usr/lib -version-info 16:0:1 -o libnetsnmpagent.la snmp_agent.lo snmp_vars.lo agent_read_config.lo agent_registry.lo agent_index.lo agent_trap.lo kernel.lo agent_handler.lo mibgroup/utilities/execute.lo mibgroup/mibII/vacm_conf.lo mibgroup/snmpv3/usmConf.lo ../snmplib/libnetsnmp.la -L/home/goranh/src/etrax/target/crisv32-axis-linux-gnu/lib -L/home/goranh/src/etraxtarget/crisv32-axis-linux-gnu/lib -L/home/goranh/src/etrax/target/crisv32-axis-linux-gnu/usr/lib -L/home/goranh/src/etrax/target/crisv32-axis-linux-gnu/usr/lib -inst-prefix-dir /home/goranh/src/etrax/target/crisv32-axis-linux-gnu) and this added at the end log-snmp-cross-relink 21 gzip log-snmp-cross-relink and post log-snmp-cross-relink.gz as well as the output of ../libtool --config ? Further, where is the cris libc located on your system? Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: build check in AIX 5.2 / 5.3 / 6.1
Hello Rainer, * Rainer Tammer wrote on Wed, Jan 09, 2008 at 12:25:03PM CET: I have checked the following libtool versions on several AIX versions: 1. branch-1.5-20080108-cvs on AIX 5.2, 5.3, 6.1 result: AIX 5.2 / branch-1.5 / OK AIX 5.3 / branch-1.5 / OK AIX 6.1 / branch-1.5 / OK 2. HEAD-20080108-cvs on AIX 5.3, 6.1 result: AIX 5.3 / HEAD / testsuite OK, FAIL: tests/mdemo-exec.test (3 times) AIX 6.1 / HEAD / testsuite OK, FAIL: tests/mdemo-exec.test (3 times) The detailed test results are in the attached archive. All test were conducted with IBM C/C++ compilers. And all tests were done with runtimelinking enabled (-brtl). It'd be cool if we could even get things to work smoothly without, but having it working with it is already good. So we basically have only one bug left with XL/runtimelinking (the mdemo-exec one). If you like me to perforce some tests with gcc then I can try that too.. Yes, that would be great. The systems I test on currently don't have g++ or gfortran (or gcj) installed, so if you could test ./configure CC=gcc CXX=g++ FC=gfortran F77=gfortran (with LDFLAGS=-Wl,-brtl added, and maybe even without) that would help a lot. Cheers, and many thanks for your work! Ralf ___ Bug-libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-libtool
make -s
Hi, When I do a 'make -s', I usually get no output from the compiler commands. However with libtool, when it goes into, mkdir .libs then I see the compiler output. Do you think this is the correct behavior? I would like to see the output suppressed in this circumstance. This is just a feature request. Thanks again for libtool. Bob Rossi ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: build check in AIX 5.2 / 5.3 / 6.1
* Rainer Tammer wrote on Wed, Jan 09, 2008 at 12:25:03PM CET:
[ branch-1.5-20080108-cvs/check.log ]
creating libmlib.la (cd .libs rm -f libmlib.la ln -s ../libmlib.la
libmlib.la) cc_r -qlanglvl=extc89 -DPACKAGE_NAME=\mdemo\
-DPACKAGE_TARNAME=\mdemo\ -DPACKAGE_VERSION=\0.1\
-DPACKAGE_STRING=\mdemo\ 0.1\ -DPACKAGE_BUGREPORT=\[EMAIL PROTECTED]
-DPACKAGE=\mdemo\ -DVERSION=\0.1\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
-DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1
-DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1
-DHAVE_DLFCN_H=1 -DHAVE_MATH_H=1 -I. -I./../libltdl-g -c main.c
main.c, line 195.7: 1506-068 (W) Operation between types char* and int
is not allowed.
While we're at it, let's fix that buglet, and a couple of other ones I
found. Applied to branch-1-5 (HEAD is fixed already).
Cheers,
Ralf
2008-01-09 Ralf Wildenhues [EMAIL PROTECTED]
* mdemo/main.c: Include string.h, for strrchr.
Report by Rainer Tammer.
* f77demo/cprogram.c: Include stdio.h, for printf.
* f77demo/fooc.c: Likewise.
Index: f77demo/cprogram.c
===
RCS file: /cvsroot/libtool/libtool/f77demo/Attic/cprogram.c,v
retrieving revision 1.1.2.1
diff -u -r1.1.2.1 cprogram.c
--- f77demo/cprogram.c 22 Apr 2005 09:05:43 - 1.1.2.1
+++ f77demo/cprogram.c 9 Jan 2008 19:53:22 -
@@ -15,6 +15,7 @@
USA. */
#include foo.h
+#include stdio.h
int
main(int argc, char **argv)
Index: f77demo/fooc.c
===
RCS file: /cvsroot/libtool/libtool/f77demo/Attic/fooc.c,v
retrieving revision 1.1
diff -u -r1.1 fooc.c
--- f77demo/fooc.c 31 Jul 2002 20:15:27 - 1.1
+++ f77demo/fooc.c 9 Jan 2008 19:53:22 -
@@ -1,4 +1,5 @@
#include foo.h
+#include stdio.h
int csub(int arg)
Index: mdemo/main.c
===
RCS file: /cvsroot/libtool/libtool/mdemo/Attic/main.c,v
retrieving revision 1.19.4.2
diff -u -r1.19.4.2 main.c
--- mdemo/main.c24 Jul 2007 05:11:13 - 1.19.4.2
+++ mdemo/main.c9 Jan 2008 19:53:22 -
@@ -1,5 +1,5 @@
/* main.c -- mdemo test program
- Copyright (C) 1998-2000, 2007 Free Software Foundation, Inc.
+ Copyright (C) 1998-2000, 2007, 2008 Free Software Foundation, Inc.
Originally by Thomas Tanner [EMAIL PROTECTED]
This file is part of GNU Libtool.
@@ -21,10 +21,12 @@
#include foo.h
#include ltdl.h
#include stdio.h
+#include string.h
int
test_dl (filename, test_ext)
char *filename;
+ int test_ext;
{
lt_dlhandle handle;
const lt_dlinfo *info;
___
Bug-libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: error while loading shared libraries: foo.so.0: cannot open shared object file: No such file or directory
[ http://thread.gmane.org/gmane.comp.gnu.libtool.general/8726 ]
Hello Laurence,
Apologies for the delay, and apologies again for not citing better,
and thanks for the report. There are two slightly differents
setups, as far as Libtool is concerned. For the first one I can
confirm your issue, but the second I think is different.
- Either /usr/local/lib is listed in /etc/ld.so.conf
and then the configure script should find that out and cause
/usr/local/lib to be listed in
./libtool --config | grep ^sys_lib_dlsearch_path_spec=
- or /usr/local/lib should not be listed in /etc/ld.so.conf
and then it may not either show up in
./libtool --config | grep ^sys_lib_dlsearch_path_spec=
If it does, then that's a separate bug that we should look at.
The second setup will cause libtool to add
-Wl,-rpath -Wl,/usr/local/lib
to the link of the program, which will cause it to find its library.
So in the following let's deal with the first setup only.
And of course only GNU/Linux.
FWIW, here's a script to reproduce the error. You may have to adjust it
for your use, and you should use it carefully as it modifies root-owned
files.
--- snip ---
#! /bin/sh
: ${SUDO=su -c} # adjust this as needed.
set -e # error out on nonzero command.
cat configure.ac 'END'
AC_INIT([ldconfig-bug], [1], [devnull])
AM_INIT_AUTOMAKE([foreign])
AC_PROG_CC
AC_PROG_LIBTOOL
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
END
cat Makefile.am 'END'
lib_LTLIBRARIES = libfoo.la
bin_PROGRAMS = foo
foo_LDADD = libfoo.la
END
cat foo.c 'END'
extern int foo ();
int main () { return foo (); }
END
echo 'int foo () { return 0; }' libfoo.c
libtoolize -c
autoreconf -vi
./configure
make
# ensure /usr/local/lib is not searched by default:
grep /usr/local/lib /etc/ld.so.conf /etc/ld.so.conf.d/* exit 1
$SUDO ldconfig
# ensure libfoo.so is not found by default:
.libs/foo exit 1
# install. This will cause `ldconfig -n /usr/local/lib' to be run:
$SUDO 'make install'
# try running. This will fail:
/usr/local/bin/foo
--- snip ---
So, what's the meat of the problem:
- libtool calls 'ldconfig -n $libdir'
- 'ldconfig -n' implies '-N' which means not to update the cache
(so all it does is add symlinks if needed; which should not be
needed due to libtool having done that work)
- ld.so however does not search all dirs in /etc/ld.so.conf.
What it does is search
-- dirs specified in LD_LIBRARY_PATH
-- candidate files from /etc/ld.so.cache
(which has not been updated yet)
-- /usr/lib and /lib
Strictly speaking, I guess libtool should call plain ldconfig.
*That* however could be unbearably slow if done for every library
being installed. One cool thing would be if ldconfig had a mode to
update the cache but by reading only one directory, as BSD ldconfig
does.
Sigh.
Cheers,
Ralf
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: make -s
Hello Bob, * Bob Rossi wrote on Wed, Jan 09, 2008 at 08:52:20PM CET: When I do a 'make -s', I usually get no output from the compiler commands. However with libtool, when it goes into, mkdir .libs then I see the compiler output. To me, you speak in riddles. Please just post what command you type, what is output, and what you expect it to output instead. ;-) Ah, and which Automake and Libtool versions you use. Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: make -s
On Wednesday 09 January 2008, Ralf Wildenhues wrote: * Bob Rossi wrote on Wed, Jan 09, 2008 at 08:52:20PM CET: When I do a 'make -s', I usually get no output from the compiler commands. However with libtool, when it goes into, mkdir .libs then I see the compiler output. To me, you speak in riddles. Please just post what command you type, what is output, and what you expect it to output instead. ;-) i figured it was a known issue that no one cared about. libtool is quite verbose in its running and will output stuff irregardless of the verbose mode make itself is running. take any package that uses libtool and run: make -s if you see any output at all about commands being run, it is incorrect. the request is to have the --silent flag passed automatically to libtool if the -s flag is passed to make. Ah, and which Automake and Libtool versions you use. any version at all should behave the same -mike signature.asc Description: This is a digitally signed message part. ___ http://lists.gnu.org/mailman/listinfo/libtool
RE: mingw install directory for shared lib
Bob Friesenhahn mailto:[EMAIL PROTECTED] wrote: On Wed, 9 Jan 2008, Duft Markus wrote: Bob Friesenhahn wrote: On Tue, 8 Jan 2008, Ralf Wildenhues wrote: General question before fixing this: on w32, should even plugins have their DLLs go to $bindir? Yes, i'd agree to this... ;o) If you try to load a library by yourself, you will have to know what you're doing. If the DLL is linked to the executable, you have no (easy) way to influence what is done by the loader... Modules should not be linked with an executable. That would surely be bad design and should not be supported. There should be no need to load a module by yourself since libtool offers libltdl which does it for you by requesting to load the associated .la file. Regardless, loading modules directly is trivially easy under Windows. Ok, i agree here. Of course there may still be problems if there are dependencies between plugins, that are installed in different directories, since loading one plugin will load all libraries this dll is linked to. If those are plugins themselves, they will have to be in PATH to be found (or in the same directory, etc.). The easiest solution is using parity ;) but thats self-advertisement again, sorry... There should be no dependencies between plugins. That would surely be bad design and should not be supported. Libtool should be supporting portable behavior. If the user does not desire to implement portable behavior, then there is little value to using libtool or libltdl. The portable definition for windows should be: library - Executables (usually) link directly with libraries and when the library is a DLL it should be installed in the executable search path, and (ideally) be in the same 'bin' directory as the dependent executables. I wrote some routines to support runpaths on windows, so i install all my libs in the lib directory ;) Also all my executables and libraries built with parity are LD_LIBRARY_PATH aware... So i can use full UNIX like semantics on windows, without any costs (except writing parity before, which of corse costed lots of nerves...) module - Modules are only loaded via an explicit loading mechanism (e.g. Windows LoadLibrary() or libltdl. Modules may depend on libraries (see above) but should not depend on other modules. Since modules are explicitly loaded, they may be installed in an application-specific lib directory (just like for Unix). When thinking of the default windows behaviour, i agree here too. Markus Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ -- 19. - 21. Februar 2008 Salomon Automation auf der LogiMAT 2008, Neue Messe Stuttgart, Deutschland Halle 6, Stand 527 23. - 27. Februar 2008 MoveRetail auf der EuroShop 2008 in Dusseldorf, Deutschland Halle 6, Stand C50 Salomon Automation GmbH - Friesachstrasse 15 - A-8114 Friesach bei Graz Sitz der Gesellschaft: Friesach bei Graz UID-NR:ATU28654300 - Firmenbuchnummer: 49324 K Firmenbuchgericht: Landesgericht fur Zivilrechtssachen Graz ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: make -s
Hello Mike, * Mike Frysinger wrote on Wed, Jan 09, 2008 at 10:17:45PM CET: the request is to have the --silent flag passed automatically to libtool if the -s flag is passed to make. alias 'make_s=make -s LIBTOOLFLAGS=--silent' For whatever output is left done by libtool I expect that whoever want's it silenced hard enough will have enough motivation to send a patch to [EMAIL PROTECTED]. Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
