This is a libtool installation issue. The problem is libgcc_s isn't a libtool library and we don't relink against the installed libgcc_s when installing libraries such as libstdc++.sl. As a result, we have a default path for libgcc_s.sl pointing to the GCC build directory. 529 (hiauly1)dave> chatr libstdc++.sl libstdc++.sl: shared library shared library dynamic path search: SHLIB_PATH disabled second embedded path enabled first /opt/gnu/gcc/gcc-4.0.2/lib internal name: libstdc++.sl.6 shared library list: dynamic /usr/lib/libM.1 dynamic /xxx/gnu/gcc-3.3/objdir/gcc/libgcc_s.sl dynamic /usr/lib/libc.1 shared vtable support disabled static branch prediction disabled kernel assisted branch prediction enabled lazy swap allocation disabled text segment locking disabled data segment locking disabled third quadrant private data space disabled fourth quadrant private data space disabled data page size: 4K instruction page size: 4K The important part is the dynamic path to libgcc_s: /xxx/gnu/gcc-3.3/objdir/gcc/libgcc_s.sl. This is the absolete path for libgcc_s.sl in the build directory rather than the install directory. The HP dynamic loader has the unfortunate characteristic of trying the default dynamic path before the embedded or SHLIB_PATH. If the build directory contains an incompatible libgcc_s.sl (e.g., 64-bit build), the installation breaks. HP-UX 11 ld has a '+nodefaultrpath' option which could fix this, but it's not available on HP-UX 10. So, it would be better if libtool linked against the installed version of libgcc_s.sl when installing other libraries which depend on it. This problem is present in all GCC versions.
Isn't this really still a dup of bug 5291?
Subject: Re: Default path for libgcc_s.sl is build directory > Isn't this really still a dup of bug 5291? Yes. I got bitten by the bug today ;( Regarding comment #8 in PR 5291: > Note that, on PA, the linker does indeed annotate an executable with the > location in which it found the library, but that's just a cache, it doesn't > require the library to be there in order to function. Libtool knows about that, > and does the right thing when linking with a libtool library, but libgcc_s isn't > a libtool library, so libtool can't do much. It's correct that the linker does annotate an executable with the location in which it finds a library when it is linked in with -l and the dynamic linker doesn't require the library to be there in order to function, but the dynamic linker will use an executable file with the correct name if it finds it in preference to doing a path search. So, one has to be very careful about doing builds for different versions and targets in different locations. The hppa64-*-hpux* situation is a little different: /bin/sh ../libtool --tag CXX --mode=link /test/gnu/gcc-4.1/objdir/./gcc/xgcc -shared-libgcc -B/test/gnu/gcc-4.1/objdir/./gcc -nostdinc++ -L/test/gnu/gcc-4.1/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src -L/test/gnu/gcc-4.1/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src/.libs -B/opt/gnu64/gcc/gcc-4.1.0/hppa64-hp-hpux11.11/bin/ -B/opt/gnu64/gcc/gcc-4.1.0/hppa64-hp-hpux11.11/lib/ -isystem /opt/gnu64/gcc/gcc-4.1.0/hppa64-hp-hpux11.11/include -isystem /opt/gnu64/gcc/gcc-4.1.0/hppa64-hp-hpux11.11/sys-include -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -o libstdc++.la -rpath /opt/gnu64/gcc/gcc-4.1.0/lib -version-info 6:7:0 -lm bitmap_allocator.lo pool_allocator.lo mt_allocator.lo codecvt.lo compatibility.lo complex_io.lo ctype.lo debug.lo debug_list.lo functexcept.lo globals_locale.lo globals_io.lo ios.lo ios_failure.lo ios_init.lo ios_locale.lo limits.lo list.lo locale.lo locale_init.lo lo! cale_facets.lo localename.lo stdexcept.lo strstream.lo tree.lo allocator-inst.lo concept-inst.lo fstream-inst.lo ext-inst.lo ios-inst.lo iostream-inst.lo istream-inst.lo istream.lo locale-inst.lo locale-misc-inst.lo misc-inst.lo ostream-inst.lo sstream-inst.lo streambuf-inst.lo streambuf.lo string-inst.lo valarray-inst.lo wlocale-inst.lo wstring-inst.lo atomicity.lo codecvt_members.lo collate_members.lo ctype_members.lo messages_members.lo monetary_members.lo numeric_members.lo time_members.lo basic_file.lo c++locale.lo ../libmath/libmath.la ../libsupc++/libsupc++convenience.la -lm *** Warning: This library needs some functionality provided by -lgcc_s. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** Warning: This library needs some functionality provided by -lgcc_s. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** Warning: This library needs some functionality provided by -lgcc_s. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** Warning: This library needs some functionality provided by -lgcc_s. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** The inter-library dependencies that have been dropped here will be *** automatically added whenever a program is linked with this library *** or is declared to -dlopen it. The result is libgcc_s isn't linked against libstdc++. I had a hppa64 libtool patch that fixed a lot of problems on this port (it needs to be handled in a manner very similar to ia64-hpux) but gave when the patch was ignored upstream. Dave
*** This bug has been marked as a duplicate of 5291 ***
(In reply to comment #2) > Subject: Re: Default path for libgcc_s.sl is build directory > > > Isn't this really still a dup of bug 5291? > > Yes. I got bitten by the bug today ;( No, it is not. At least not exactly, from the Libtool POV: they likely need different fixes. > The hppa64-*-hpux* situation is a little different: > > The result is libgcc_s isn't linked against libstdc++. > > I had a hppa64 libtool patch that fixed a lot of problems on this port > (it needs to be handled in a manner very similar to ia64-hpux) but gave > when the patch was ignored upstream. Please point me to your patch. Cheers, Ralf
Subject: Re: Default path for libgcc_s.sl is build directory > > I had a hppa64 libtool patch that fixed a lot of problems on this port > > (it needs to be handled in a manner very similar to ia64-hpux) but gave > > when the patch was ignored upstream. > > Please point me to your patch. Attached. The diff is against libtool in binutils as about July 28, 2005. Dave
Created attachment 10914 [details] libtool.d.3
(In reply to comment #5) > > > > I had a hppa64 libtool patch that fixed a lot of problems on this port > > > (it needs to be handled in a manner very similar to ia64-hpux) but gave > > > when the patch was ignored upstream. > > > > Please point me to your patch. > > Attached. The diff is against libtool in binutils as about July 28, 2005. Similar changes have entered both branch-1-5 and HEAD Libtool more than 2 years ago; branch-1-4 is long dead. I can only guess that's why it was ignored. ;-) HPPA support has evolved a bit since. There is BTW a pending patch (both branches): http://article.gmane.org/gmane.comp.gnu.libtool.general/7083 Cheers, Ralf
Subject: Re: Default path for libgcc_s.sl is build directory > > > Please point me to your patch. > > > > Attached. The diff is against libtool in binutils as about July 28, 2005. > > Similar changes have entered both branch-1-5 and HEAD Libtool more than 2 years > ago; branch-1-4 is long dead. I can only guess that's why it was ignored. ;-) Actually, I see that I first starting hacking the hppa64 implementation back in July 2002. I also see Albert Chin and I discussed a somewhat set of changes in early in 2003. So, I guess that's why I developed the impression. Thanks for looking it over. Regarding the hardcoding problem, the HP-UX 11 ld option '+nodefaultrpath' looks like it might be useful. It seems to be used for ia64 but not hppa*64*, or hppa in general on hpux11. Dave
> Regarding the hardcoding problem, the HP-UX 11 ld option '+nodefaultrpath' > looks like it might be useful. It seems to be used for ia64 but not > hppa*64*, or hppa in general on hpux11. I can not find references to this option in the manpages for hppa ld, not even the presumably latest: http://docs.hp.com/en/B2355-60105/ld_pa.1.html unlike for ia64. Cheers, Ralf
Subject: Re: Default path for libgcc_s.sl is build directory > ------- Comment #9 from Ralf dot Wildenhues at gmx dot de 2006-02-28 09:23 ------- > > Regarding the hardcoding problem, the HP-UX 11 ld option '+nodefaultrpath' > > looks like it might be useful. It seems to be used for ia64 but not > > hppa*64*, or hppa in general on hpux11. > > I can not find references to this option in the manpages for hppa ld, not > even the presumably latest: http://docs.hp.com/en/B2355-60105/ld_pa.1.html > unlike for ia64. I see it in the manpages for both HP-UX 11.00 and 11.11. I have the following "ld(1) and linker tools" patches installed: PHSS_30965 and PHSS_30968. I see in the text for PHSS_30049: - JAGae91522: linker records build-time library paths Resolution: Provided a linker option +nodefaultrpath for not recording build-time paths in the resultant executables and shared libraries Dave
(In reply to comment #10) > > I see it in the manpages for both HP-UX 11.00 and 11.11. I have > the following "ld(1) and linker tools" patches installed: PHSS_30965 > and PHSS_30968. I see in the text for PHSS_30049: > Provided a linker option +nodefaultrpath for > not recording build-time paths in the resultant > executables and shared libraries So how can we find out cheaply whether it's supported? Even if it is ignored when not supported: we could also set hardcode_minus_L=no if supported to get the chance to save some relinking. Cheers, Ralf
Subject: Re: Default path for libgcc_s.sl is build directory > (In reply to comment #10) > > > > I see it in the manpages for both HP-UX 11.00 and 11.11. I have > > the following "ld(1) and linker tools" patches installed: PHSS_30965 > > and PHSS_30968. I see in the text for PHSS_30049: > > > Provided a linker option +nodefaultrpath for > > not recording build-time paths in the resultant > > executables and shared libraries > > So how can we find out cheaply whether it's supported? Even if it is ignored > when not supported: we could also set hardcode_minus_L=no if supported to get > the chance to save some relinking. The option seems to be ignored by ld when not supported (tested on HP-UX 10.20 and HP-UX 11.11). 507 (hiauly1)dave> cat main.c int main() {} 508 (hiauly1)dave> gcc -o main -Wl,+nodefaultrpath main.c This is the not supported case (HP-UX 10.20): 509 (hiauly1)dave> chatr main|grep libc dynamic /usr/lib/libc.1 This is the supported case (HP-UX 11.11): -bash-2.05b$ chatr main|grep libc dynamic libc.2 So, a small shell script should be able to detect the difference. For example, 514 (hiauly1)dave> chatr main|grep 'dynamic[ \t]*libc' 515 (hiauly1)dave> echo $? 1 -bash-2.05b$ chatr main|grep 'dynamic[ \t]*libc' dynamic libc.2 -bash-2.05b$ echo $? 0 The above compilation also works using 'cc' instead of 'gcc'. Dave
Subject: Re: Default path for libgcc_s.sl is build directory > This is the not supported case (HP-UX 10.20): > 509 (hiauly1)dave> chatr main|grep libc > dynamic /usr/lib/libc.1 Also, -bash-2.05b$ ./main /usr/lib/dld.sl: Can't open shared library: libc.2 /usr/lib/dld.sl: No such file or directory ABORT instruction (core dumped) GCC and cc don't enable the dynamic search by default in the 32-bit runtime. Thus, there's no way for the dynamic loader to open libc when the option is supported. The situations is different in the 64-bit runtime: -bash-2.05b$ chatr main main: 64-bit ELF executable shared library dynamic path search: LD_LIBRARY_PATH enabled first SHLIB_PATH enabled second embedded path enabled third Not Defined shared library list: libc.2 Dave
Subject: Re: Default path for libgcc_s.sl is build directory > The situations is different in the 64-bit runtime: > > -bash-2.05b$ chatr main > main: > 64-bit ELF executable > shared library dynamic path search: > LD_LIBRARY_PATH enabled first > SHLIB_PATH enabled second > embedded path enabled third Not Defined > shared library list: > libc.2 The effect of the option in the 64-bit runtime is to not enter the -L directories specified in the ld command in the embedded path. Without the option, the embedded path using gcc looks something like: embedded path enabled third /home/gnu64/gcc/gcc-3.4.5/bin/../lib/gcc/hppa64-hp-hpux11.11/3.4.5:/home/gnu64/gcc/gcc-3.4.5/bin/../lib/gcc:/opt/gnu64/gcc/gcc-3.4.5/lib/gcc/hppa64-hp-hpux11.11/3.4.5:/usr/ccs/bin:/usr/ccs/lib/pa20_64:/opt/langtools/lib/pa20_64:/home/gnu64/gcc/gcc-3.4.5/bin/../lib/gcc/hppa64-hp-hpux11.11/3.4.5/../../..:/opt/gnu64/gcc/gcc-3.4.5/lib/gcc/hppa64-hp-hpux11.11/3.4.5/../../.. With the option, +b can be used to set the embedded path to whatever. Dave
Subject: Re: Default path for libgcc_s.sl is build directory > > Attached. The diff is against libtool in binutils as about July 28, 2005. > > Similar changes have entered both branch-1-5 and HEAD Libtool more than 2 years > ago; branch-1-4 is long dead. I can only guess that's why it was ignored. ;-) > > HPPA support has evolved a bit since. There is BTW a pending patch (both > branches): http://article.gmane.org/gmane.comp.gnu.libtool.general/7083 The problem is the new HPPA support isn't in the GCC or Sourceware trees. However, I'm beginning to think the HPPA support for shared libraries is totally wrong (i.e., linking in dependent shared libraries in shared links). First, see the recommendations in <http://docs.hp.com/en/1896/pthreads.html>. HP libc contains stubs for the pthread stubs. So, for example, when we link libstdc++ against libc, we end up with the following dependencies: -bash-2.05b$ chatr libstdc++.sl libstdc++.sl: shared library shared library dynamic path search: SHLIB_PATH disabled second embedded path enabled first /opt/gnu/gcc/gcc-4.1.0/lib internal name: libstdc++.sl.6 shared library list: dynamic /usr/lib/libm.2 dynamic /test/gnu/gcc-4.1/objdir/./gcc/libgcc_s.sl dynamic /usr/lib/libc.2 So, libstdc++.sl is linked against the pthread stubs in libc instead of the real pthread functions in libpthread. I'm not sure I fully understand how binding affects symbol resolution. The default binding is deferred, and in that case function references are trapped via the linkage table and bound on the first reference. If the first pthread reference comes from libstdc++, I think the application will bind to the pthread stub functions in libc. On the other hand, if the first reference comes from from some other place it may bind against routines in libpthread. Thus, the default binding with the current scheme is likely unpredictable or may change as libraries load. Linking dependent libraries into shared libraries also makes it more likely that multiple incompatible versions would be used in an application. I don't think you will find any HP shared libraries that have similar dependencies. I've recently been trying to get Java working under HP-UX and haven't yet found a version of gdb that can handle backtraces correctly because they all get the shared library locations wrong. This is probably because the dynamic loader is loading multiple versions of a library. I think a better approach would be to not link in any dependent shared libraries in shared links. As far as I can tell, there aren't any issues with undefined symbols (at least in HP-UX 11). Thoughts? Dave
Hi I am getting the following error when I run a concurrent programs in Oracle R12.1.3, which calls a Pro *C executable. /usr/lib/dld.sl: Can't find path for shared library: libstdc++.sl.5 /usr/lib/dld.sl: No such file or directory /d701/oracle/cfo/bin/CFORPPL Program was terminated by signal 6 ----------------------------------------------------------------------------------------- more information : we have libstdc++.sl.5 available in the path /usr/lib/. An ls -ltr in /usr/lib/ gives ls -ltr libstdc++.sl.5 lrwx------ 1 root sys 35 Feb 28 2012 libstdc++.sl.5 -> /usr/syncsort/lib/libstdc++.sl.5_32 similarly an ls -ltr in /usr/syncsort/lib/ gives -rwxr-xr-x 1 root sys 5768296 Feb 8 2006 /usr/syncsort/lib/libstdc++.sl.5 I am not sure what is the issue?? For apps mgr /home/appsimd1>echo $SHLIB_PATH /d701/oracle/apps/apps_st/appl/pay/12.0.0/vendor/quantum/lib: /d701/oracle/apps/tech_st/10.1.2/jdk/jre/lib/PA_RISC2.0: /d701/oracle/apps/tech_st/10.1.2/jdk/jre/lib/PA_RISC2.0/server: /d701/oracle/apps/apps_st/appl/cz/12.0.0/bin: /d701/oracle/apps/tech_st/10.1.2/lib32: /d701/oracle/apps/tech_st/10.1.2/lib: /usr/dt/lib: /d701/oracle/apps/tech_st/10.1.2/jdk/jre/lib/PA_RISC2.0: /d701/oracle/apps/tech_st/10.1.2/jdk/jre/lib/PA_RISC2.0/server: /d701/oracle/apps/apps_st/appl/sht/12.0.0/lib: /d701/oracle/apps/tech_st/10.1.2/lib: /usr/lib: /usr/syncsort/lib but for a normal user <imd1> echo $SHLIB_PATH /d701/oracle/apps/apps_st/appl/pay/12.0.0/vendor/quantum/lib: /d701/oracle/apps/tech_st/10.1.2/jdk/jre/lib/PA_RISC2.0: /d701/oracle/apps/tech_st/10.1.2/jdk/jre/lib/PA_RISC2.0/server: /d701/oracle/apps/apps_st/appl/cz/12.0.0/bin: /d701/oracle/apps/tech_st/10.1.2/lib32: /d701/oracle/apps/tech_st/10.1.2/lib: /usr/dt/lib: /d701/oracle/apps/tech_st/10.1.2/jdk/jre/lib/PA_RISC2.0: /d701/oracle/apps/tech_st/10.1.2/jdk/jre/lib/PA_RISC2.0/server: /d701/oracle/apps/apps_st/appl/sht/12.0.0/lib: /usr/syncsort/lib: /opt/microfocus/cobol/lib I am not sure what is the unix user the Oracle Concurrent program is using. Is it a path issue? Please help
On 3-Oct-12, at 6:18 PM, anilkris at hotmail dot com wrote: > I am getting the following error when I run a concurrent programs in > Oracle > R12.1.3, which calls a Pro *C executable. > > /usr/lib/dld.sl: Can't find path for shared library: libstdc++.sl.5 > /usr/lib/dld.sl: No such file or directory > /d701/oracle/cfo/bin/CFORPPL > Program was terminated by signal 6 This issue isn't related to bug. Whether SHLIB_PATH is used or not depends on how applications and libraries are linked. The chatr program can be used to see how an application or library has been linked, and the library paths. It may be possible to use chatr to adjust the settings so the error doesn't occur. Library paths are hardcoded during linking. -- John David Anglin dave.anglin@bell.net
Not sure whether the issue I got is related to this bug: When using GCC to compile a C program, the binary got is linked with a libgcc_s.4 under the HP-GCC 4.7.1 installed directory /opt/hp-gccxxx/xx/yy/../zz/aa/../, and to run the program on another machine, that machine has to install the GCC also, that's very bad. My question is why can't GCC generate a static lib for those functions that must be used for the binary to run and linked with the program statically? Isn't that will remove the dependency to GCC package for running the program? I'm using hp-gcc-4.7.1.
On 11-Aug-14, at 7:26 PM, wzis at hotmail dot com wrote: > Not sure whether the issue I got is related to this bug: When using > GCC to > compile a C program, the binary got is linked with a libgcc_s.4 > under the > HP-GCC 4.7.1 installed directory /opt/hp-gccxxx/xx/yy/../zz/aa/../, > and to run > the program on another machine, that machine has to install the GCC > also, > that's very bad. My question is why can't GCC generate a static lib > for those > functions that must be used for the binary to run and linked with > the program > statically? Isn't that will remove the dependency to GCC package for > running > the program? I'm using hp-gcc-4.7.1. The main problem is the HP linker hard codes shared library paths into applications and shared libraries. There are ways to manipulate the shared library search path with chatr and link options. Check out the man pages for chatr and ld. A static libgcc.a is installed and will be used with -static or - static-libgcc linker options. This will avoid the hard-coded dependence on the installation path to libgcc_s.4. Dave -- John David Anglin dave.anglin@bell.net