[Bug target/26472] Default path for libgcc_s.sl is build directory

[Bug target/26472] Default path for libgcc_s.sl is build directory

[anilkris at hotmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26472

Anil Krishnan <anilkris at hotmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |anilkris at hotmail dot com

--- Comment #16 from Anil Krishnan <anilkris at hotmail dot com> 2012-10-03 22:18:59 UTC ---
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

[Bug target/26472] Default path for libgcc_s.sl is build directory

[dave.anglin at bell dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26472

--- Comment #17 from dave.anglin at bell dot net 2012-10-03 22:39:46 UTC ---
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

[Bug target/26472] Default path for libgcc_s.sl is build directory

[wzis at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26472

wzis <wzis at hotmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wzis at hotmail dot com

--- Comment #18 from wzis <wzis at hotmail dot com> ---
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.

[Bug target/26472] Default path for libgcc_s.sl is build directory

[dave.anglin at bell dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26472

--- Comment #19 from dave.anglin at bell dot net ---
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

[Bug target/26472] Default path for libgcc_s.sl is build directory

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #15 from dave at hiauly1 dot hia dot nrc dot ca  2006-03-10 01:25 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26472

[Bug target/26472] Default path for libgcc_s.sl is build directory

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #14 from dave at hiauly1 dot hia dot nrc dot ca  2006-03-01 16:06 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26472

[Bug target/26472] Default path for libgcc_s.sl is build directory

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #13 from dave at hiauly1 dot hia dot nrc dot ca  2006-03-01 15:48 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26472

[Bug target/26472] Default path for libgcc_s.sl is build directory

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #12 from dave at hiauly1 dot hia dot nrc dot ca  2006-03-01 14:46 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26472

[Bug target/26472] Default path for libgcc_s.sl is build directory

[Ralf dot Wildenhues at gmx dot de]

------- Comment #11 from Ralf dot Wildenhues at gmx dot de  2006-03-01 07:24 -------
(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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26472

[Bug target/26472] Default path for libgcc_s.sl is build directory

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca  2006-02-28 14:32 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26472

[Bug target/26472] Default path for libgcc_s.sl is build directory

[Ralf dot Wildenhues at gmx dot de]

------- 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.

Cheers,
Ralf


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26472

[Bug target/26472] Default path for libgcc_s.sl is build directory

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca  2006-02-26 21:11 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26472

[Bug target/26472] Default path for libgcc_s.sl is build directory

[Ralf dot Wildenhues at gmx dot de]

------- Comment #7 from Ralf dot Wildenhues at gmx dot de  2006-02-26 17:19 -------
(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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26472

[Bug target/26472] Default path for libgcc_s.sl is build directory

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca  2006-02-26 15:37 -------
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


------- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca  2006-02-26 15:37 -------
Created an attachment (id=10914)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10914&action=view)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26472

[Bug target/26472] Default path for libgcc_s.sl is build directory

[Ralf dot Wildenhues at gmx dot de]

------- Comment #4 from Ralf dot Wildenhues at gmx dot de  2006-02-26 06:40 -------
(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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26472

[Bug target/26472] Default path for libgcc_s.sl is build directory

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca  2006-02-26 02:50 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26472

[Bug target/26472] Default path for libgcc_s.sl is build directory

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2006-02-26 02:58 -------


*** This bug has been marked as a duplicate of 5291 ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26472

[Bug target/26472] Default path for libgcc_s.sl is build directory

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2006-02-26 01:39 -------
Isn't this really still a dup of bug 5291?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26472