Problem with '-L' switch.
Hello. Can you advise me on this, please? I build a library with libtool, say libbig.la, from C++ sources, on IA32. This libbig.la wants to link to libsmall.la as '-lsmall' . But, during creating libbig.la, g++ has '-L/usr/lib' before my (user's) paths, which is undesitable in my situation. This '-L/usr/lib' is there only in the case, when libsmall.la has non-empty 'Library Rpath' section in ELF (you find this with 'readelf --dynamic libsmall.so'). When I arrange for libsmall to have this 'Library Rpath' section empty, then '-L/usr/lib' goes away. As it seems. And this problem seems to depend on some other configuration of Linux system. On AMD64 it does not occur, although the versions of libtool are the same. Thank you. V. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Problem with '-L' switch.
Hello Vaclav, * Vaclav Havlik wrote on Wed, Aug 16, 2006 at 03:42:17PM CEST: I build a library with libtool, say libbig.la, from C++ sources, on IA32. This libbig.la wants to link to libsmall.la as '-lsmall' . But, during creating libbig.la, g++ has '-L/usr/lib' before my (user's) paths, which is undesitable in my situation. You mean libtool adds the -L/usr/lib? In order to be able to find out why it does that, please send the output of ./libtool --tag=CXX --config ./libtool --debug --tag=CXX --mode=link g++ -o libbig.la ... (the second command is supposed to be the link line for libbig.la, with the argument --debug added). Please pack large output with gzip. As it seems. And this problem seems to depend on some other configuration of Linux system. On AMD64 it does not occur, although the versions of libtool are the same. Yes, it depends on the system and some other things whether this could happen (for example the values of the sys_lib_*search_path_spec variables). Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Problem with '-L' switch.
Hello Vaclav, Please keep the mailing list in Cc:. Thanks. * Vaclav Havlik wrote on Wed, Aug 16, 2006 at 04:28:06PM CEST: /bin/sh ~/work/PAS/libtool --debug --tag=CXX --mode=link g++ -Wall -g -D_REENTRANT -D_FILE_OFFSET_BITS=64 -pedantic -Wno-long-long -L../../lib -L/opt/pas/lib -L/opt/pas/lib64 -L../../lib -L/opt/pas/lib -L/opt/pas/lib64 -o libPASncl.la -rpath /home/Vaclav/shared/lib -version-info 1:0:0 PASncl.lo PASnclThreads.lo PASnclSimple.lo PASnclMt.lo PASnclUtils.lo PASnclQueue.lo PASnclSSL.lo CJobNumber.lo -lpas -lssl 1debug1.txt 2debug2.txt [...] g++ -shared -nostdlib /usr/lib/gcc/i386-redhat-linux/3.4.5/../../../crti.o /usr/lib/gcc/i386-redhat-linux/3.4.5/crtbeginS.o .libs/PASncl.o .libs/PASnclThreads.o .libs/PASnclSimple.o .libs/PASnclMt.o .libs/PASnclUtils.o .libs/PASnclQueue.o .libs/PASnclSSL.o .libs/CJobNumber.o -Wl,--rpath -Wl,/home/Vaclav/work/PAS/lib/.libs -Wl,--rpath -Wl,/home/Vaclav/shared/lib -L/usr/lib -L/home/Vaclav/work/PAS/lib/.libs -L/home/Vaclav/work/PAS/lib -L/opt/pas/lib -L/opt/pas/lib64 /home/Vaclav/work/PAS/lib/.libs/libpas.so -lssl -L/usr/lib/gcc/i386-redhat-linux/3.4.5 -L/usr/lib/gcc/i386-redhat-linux/3.4.5/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/i386-redhat-linux/3.4.5/crtendS.o /usr/lib/gcc/i386-redhat-linux/3.4.5/../../../crtn.o -Wl,-soname -Wl,libPASncl.so.1 -o .libs/libPASncl.so.1.0.0 The addition of `-L/usr/lib' is a genuine Libtool bug. The cause is the non-normalization of the search paths: # Compile-time system search path for libraries sys_lib_search_path_spec= /usr/lib/gcc/i386-redhat-linux/3.4.5/ /usr/lib/gcc/i386-redhat-linux/3.4.5/ /usr/lib/gcc/i386-redhat-linux/3.4.5/../../../../i386-redhat-linux/lib/i386-redhat-linux/3.4.5/ /usr/lib/gcc/i386-redhat-linux/3.4.5/../../../../i386-redhat-linux/lib/ /usr/lib/gcc/i386-redhat-linux/3.4.5/../../../i386-redhat-linux/3.4.5/ /usr/lib/gcc/i386-redhat-linux/3.4.5/../../../ /lib/i386-redhat-linux/3.4.5/ /lib/ /usr/lib/i386-redhat-linux/3.4.5/ /usr/lib/ Note how the above contains `/usr/lib/' instead of `/usr/lib' at the very end? Please try the following: edit the libtool script, and remove the final slash. (The sys_lib_search_path_spec is initialized once near the beginning of the libtool script, and several times at the end, for C++ and other languages. Edit all instances.) Please report back if that fixes it. By the way: # Run-time system search path for libraries sys_lib_dlsearch_path_spec=/lib /usr/lib include ld.so.conf.d/*.conf /usr/X11R6/lib /usr/local/lib This should be fixed in a newer Libtool release. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
-dlopen self and optimizing away symbols
Just built openldap-2.3.25 on HP-UX 11.23/IA. 'make check' fails because a symbol wasn't available in the main binary which dlopen()'ed a module that required the symbol. The main binary was built with -dlopen self. The problem is, after the symbols were extracted from all .o objects that comprise the main binary, the main binary was then linked with: /bin/sh ../..//libtool --mode=link cc -z +O2 +Onofltacc \ +Olit=all +Oentrysched +DD64 +Odataprefetch +Onolimit +We901 \ -L/opt/TWWfsw/libsasl21/lib/hpux64 \ -L/opt/TWWfsw/libopenssl097/lib/hpux64 \ -L/opt/TWWfsw/libdb42/lib/hpux64 \ -Wl,+b,/opt/TWWfsw/openldap2325lib/hpux64:/opt/TWWfsw/libdb42/lib/hpux64:/opt/TWWfsw/libsasl21/lib/hpux64:/opt/TWWfsw/libopenssl097/lib/hpux64 \ -dlopen self -o slapd main.o globals.o bconfig.o config.o daemon.o connection.o search.o ... rm -f .libs/slapd.nm .libs/slapd.nmS .libs/slapd.nmT creating .libs/slapdS.c generating symbol list for `slapd' extracting global C symbols from `main.o' extracting global C symbols from `globals.o' extracting global C symbols from `bconfig.o' extracting global C symbols from `config.o' extracting global C symbols from `daemon.o' ... (cd .libs cc -z +O2 +Onofltacc +Olit=all +Oentrysched +DD64 +Odataprefetch +Onolimit +We901 -c -DPIC slapdS.c) cc -z +O2 +Onofltacc +Olit=all +Oentrysched +DD64 +Odataprefetch \ +Onolimit +We901 -Wl,+b \ -Wl,/opt/TWWfsw/openldap2325lib/hpux64:/opt/TWWfsw/libdb42/lib/hpux64:/opt/TWWfsw/libsasl21/lib/hpux64:/opt/TWWfsw/libopenssl097/lib/hpux64 \ .libs/slapdS.o -o .libs/slapd main.o globals.o bconfig.o config.o \ daemon.o ... Unfortunately, the HP-UX 11.23/IA compiler, when generating .libs/slapd, will optimize _away_ symbols that are not used by any of the object files being linked: $ nm .libs/slapd | grep backend_add $ nm .libs/slapd | grep backend_group [947]| 4611686018428014688| 176|FUNC |GLOB |0| .text|backend_group $ nm main.o globals.o bconfig.o config.o ... | grep backend_add [129]| 0| 800|FUNC |GLOB |0| .text|backend_add $ nm main.o globals.o bconfig.o config.o ... | grep backend_group [157]| 0| 176|FUNC |GLOB |0| .text|backend_group [71] | 0| 0|FUNC |GLOB |0| UNDEF|backend_group [43] | 0| 0|FUNC |GLOB |0| UNDEF|backend_group How do we solve this? I suppose we could build without CFLAGS but then we'd lose +DD64 for 64-bit objects. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: -dlopen self and optimizing away symbols
Hello Albert, * Albert Chin wrote on Thu, Aug 17, 2006 at 12:39:25AM CEST: Just built openldap-2.3.25 on HP-UX 11.23/IA. 'make check' fails because a symbol wasn't available in the main binary which dlopen()'ed a module that required the symbol. The main binary was built with -dlopen self. Unfortunately, the HP-UX 11.23/IA compiler, when generating .libs/slapd, will optimize _away_ symbols that are not used by any of the object files being linked: Which compiler option causes it to optimize away the symbols? Which linker option is that translated to? How do we solve this? I suppose we could build without CFLAGS but then we'd lose +DD64 for 64-bit objects. Probably adding a linker flag at the end to undo the dangerous setting should be safest, given there is such a flag. But say, why is -Wl,-E not passed to the link line? It should be export_dynamic_flag_spec. And it should have the desired effect: | -E Mark all symbols defined by a program for export | to shared libraries. In a +compat mode link, ld | marks only those symbols that are actually | referenced by a shared library seen at link time. | In a +std link, all symbols are exported by | default, so -E is not necessary to make symbols | visible. However, it has an additional side | effect of identifying all exported symbols as | necessary, so that they will not be removed when | using dead code elimination (+Oprocelim). Otherwise, -Wl,+Onoprocelim should be the hammer we're looking for, I guess; but that should not even be necessary, given above documentation (from ld(1)). Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: -dlopen self and optimizing away symbols
On Thu, Aug 17, 2006 at 07:42:00AM +0200, Ralf Wildenhues wrote: * Albert Chin wrote on Thu, Aug 17, 2006 at 12:39:25AM CEST: Just built openldap-2.3.25 on HP-UX 11.23/IA. 'make check' fails because a symbol wasn't available in the main binary which dlopen()'ed a module that required the symbol. The main binary was built with -dlopen self. Unfortunately, the HP-UX 11.23/IA compiler, when generating .libs/slapd, will optimize _away_ symbols that are not used by any of the object files being linked: Which compiler option causes it to optimize away the symbols? +O2. +O1 and no optimization seem to be ok. Which linker option is that translated to? +O2 passes +Oprocelim to ld. How do we solve this? I suppose we could build without CFLAGS but then we'd lose +DD64 for 64-bit objects. Probably adding a linker flag at the end to undo the dangerous setting should be safest, given there is such a flag. But say, why is -Wl,-E not passed to the link line? It should be export_dynamic_flag_spec. And it should have the desired effect: | -E Mark all symbols defined by a program for export | to shared libraries. In a +compat mode link, ld | marks only those symbols that are actually | referenced by a shared library seen at link time. | In a +std link, all symbols are exported by | default, so -E is not necessary to make symbols | visible. However, it has an additional side | effect of identifying all exported symbols as | necessary, so that they will not be removed when | using dead code elimination (+Oprocelim). Because -export-dynamic is not specified. Otherwise, -Wl,+Onoprocelim should be the hammer we're looking for, I guess; but that should not even be necessary, given above documentation (from ld(1)). Well, export_dynamic_flag_spec isn't even looked at when -dlopen self is being handled. Maybe it should and only use the -dlopen self code when export_dynamic_flag_spec is empty? If not, looks like we'll need to add +Onoprocelim to the cc command-line for HP-UX. What's the best way to do this? A new variable? -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
