[Bug libstdc++/32354] New: libstdc++.so.6 missing RPATH

[Bug libstdc++/32354] New: libstdc++.so.6 missing RPATH

[stephan dot bergmann at sun dot com]

This seems to be relevant for all gcc versions, checked an old 3.4.1 and the
latest 4.3-20070608:  The libstdc++.so.6 in the installation's lib directory
has a recorded dependency on libgcc_s.so.1, also located in the installation's
lib directory, but lacks a corresponding RPATH ($ORIGIN).


-- 
           Summary: libstdc++.so.6 missing RPATH
           Product: gcc
           Version: 3.4.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: stephan dot bergmann at sun dot com
  GCC host triplet: i686-pc-linux


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

[Bug libstdc++/32354] libstdc++.so.6 missing RPATH

[pcarlini at suse dot de]

------- Comment #1 from pcarlini at suse dot de  2007-06-15 13:45 -------
Please remind us why exactly we want it and / or which specific problem you are
experiencing


-- 


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

[Bug libstdc++/32354] libstdc++.so.6 missing RPATH

[stephan dot bergmann at sun dot com]

------- Comment #2 from stephan dot bergmann at sun dot com  2007-06-15 14:00 -------
see <http://www.openoffice.org/issues/show_bug.cgi?id=78390>


-- 


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

[Bug libstdc++/32354] libstdc++.so.6 missing RPATH

[pcarlini at suse dot de]

------- Comment #3 from pcarlini at suse dot de  2007-06-15 14:41 -------
I'm not an expert of these matters, but I'm trying to understand this issue in
better detail. First, there is the info at the end of this page:

  http://gcc.gnu.org/onlinedocs/libstdc++/install.html

>From that info, I suspect RPATH may be missing on purpose (for example, myself
I'm consistenly using LD_LIBRARY_PATH, while developing the library (note, I
was not active yet, when the info above has been added)), and Libtool is
expected to help people not willing to enter in such issues...


-- 


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

[Bug libstdc++/32354] libstdc++.so.6 missing RPATH

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2007-06-15 15:14 -------
RPATH is evil.  Yes others say LD_LIBRARY_PATH is evil, but RPATH is worse.  It
forces that version of the library to be used and no other version can be used.
 So if you install libstdc++/libgcc_s.so in a different location than what
RPATH says, it will not work.

This is why it is not set for libstdc++ and other GCC libraries.


-- 

pinskia at gcc dot gnu dot org changed:

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


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

[Bug libstdc++/32354] libstdc++.so.6 missing RPATH

[stephan dot bergmann at sun dot com]

------- Comment #5 from stephan dot bergmann at sun dot com  2007-06-18 06:54 -------
Re #3:  <http://gcc.gnu.org/onlinedocs/libstdc++/install.html#usage> is not
relevant here.  That info is about how client code can find libstdc++.so.  This
issue is about how libstdc++.so can find the libraries it itself depends on.

Re #4:  Not sure I understand you completely.  If you move libstdc++.so and
libgcc_s.so somewhere else but keep their relative locations intact (i.e., both
in the same directory), RPATH=$ORIGIN in libstdc++.so still works to locate the
matching libgcc_s.so.


-- 


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

[Bug libstdc++/32354] libstdc++.so.6 missing RPATH

[joerg dot richter at pdv-fs dot de]

------- Comment #6 from joerg dot richter at pdv-fs dot de  2009-07-15 13:15 -------
I stumpled across the same problem recently.

Executable references both libstdc++.so and libgcc_s.so.
libstdc++.so references libgcc_s.so.

Both executable dependencies will be correctly resolved (due to RPATH).

But when the dynamic linker tries to resolve the second reference to
libgcc_s.so it is not using the RPATH of the executable.  Only the (not
existing) RPATH of libstdc++.so.  Which is correct IMHO.

So it goes on and tries the system default search directories. There it finds
another libgcc_s.so.  But this time it is an old version.  The executable
refused to start, because some versioned symbols could not be found.

If libstdc++.so would be linked with -rpath '$ORIGIN' this would work. 

Note that this even works, when libstdc++.so and libgcc_s.so are moved to a
different location.

So I think this bug should be reopened.

Note: this was observed on solaris2.10


-- 

joerg dot richter at pdv-fs dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |joerg dot richter at pdv-fs
                   |                            |dot de


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

[Bug libstdc++/32354] libstdc++.so.6 missing RPATH

[paolo dot carlini at oracle dot com]

------- Comment #7 from paolo dot carlini at oracle dot com  2009-07-15 14:18 -------
At minimum, somebody should check if it's still true that this possible issue
isn't limited to libstdc++. Then the course of action will be very simple:
again invalid or not a libstdc++ proper issue or a fix to be trivially copied
over from the other libraries, nothing else.


-- 


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

[Bug libstdc++/32354] libstdc++.so.6 missing RPATH

[joerg dot richter at pdv-fs dot de]

------- Comment #8 from joerg dot richter at pdv-fs dot de  2009-07-15 15:13 -------
If you mean that i.e. libgomp.so.1.0.0 and libssp.so.0.0.0 have the same bug. 
Than yes. They reference libgcc_s.so.1 without setting RPATH to '$ORIGIN'.

So this issue isn't libstdc++ specific.  Changing component to something 
different might be appropriate.

Please note that changing/adding the RPATH after a library/executable has 
been built is not trivial and has let to different more or less hackish 
solutions:

http://blogs.sun.com/ali/entry/changing_elf_runpaths
http://linux.die.net/man/1/chrpath
http://nixos.org/patchelf.html

Unfortunately non of which works for me.


-- 


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

[Bug libstdc++/32354] libstdc++.so.6 missing RPATH

[redi at gcc dot gnu dot org]

------- Comment #9 from redi at gcc dot gnu dot org  2010-04-21 16:08 -------
I've just been bitten by this on Solaris 10, and I think lots more people will
be now that gcc 4.5.0 has been released.

The problem is made worse if libstdc++ (or libgomp etc.) is built with symbol
versioning enabled because libstdc++.so.6 depends on "libgcc_s.so.1
(GCC_4.2.0)" rather than just "libgcc_s.so.1"

The 4.2.0 version is needed for _Unwind_GetIPInfo which was added in 4.2.0 (see
Bug 27880 et al) and symbol versioning was not used by default on Solaris prior
to 4.5.0, see Bug 38923

It is not enough to set the executable's RPATH because, as mentioned in comment
6, only the RPATH in libstdc++.so is used when resolving its dependencies, not
the RPATH in the executable.  I believe this is a difference between Solaris
and Linux, I think Linux's ld.so uses the executable's RPATH when searching for
a shared library's dependencies, Solaris' ld.so.1 *only* uses the RPATH in the
shared library when searching for that library's dependncies.

This forces the user to use LD_LIBRARY_PATH, rather than letting them choose
whether they want to use environment variables at runtime or rely on link-time
RPATH values.  Whether you think LD_LIBRARY_PATH is more or less evil than
RPATH is your business, but I want to be able to make my own decision.

I agree that libstdc++ should set RPATH to $ORIGIN, at least on Solaris.  It's
less important on Linux, since setting RPATH in the final executable will find
the desired libgcc_s.so

I've removed i686-linux from the Host field, since this is not specific to
Linux and is actually a bigger problem on Solaris, where if libgcc_s.so is
installed at all it is usually a much older version than on modern Linux
distros e.g. /usr/sfw/bin/gcc is 3.4.3 on Solaris 10

My workaround is to export LD_RUN_PATH='$ORIGIN' in my environment before I
build gcc, but it would be nice if there was a configure option to do that for
all the libs that depend on libgcc_s.so


-- 

redi at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |redi at gcc dot gnu dot org
   GCC host triplet|i686-pc-linux               |


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

[Bug libstdc++/32354] libstdc++.so.6 missing RPATH

[redi at gcc dot gnu dot org]

------- Comment #10 from redi at gcc dot gnu dot org  2010-04-21 16:13 -------
P.S. the workaround is a hack and not ideal, because it adds RPATH=$ORIGIN to
every binary object that gets built including the front-end drivers, cc1plus,
collect2 etc.  but it is only needed by shared libs that depend on libgcc_s.so

That's why I'd rather see a configure option which would cause it to be set
only when building those libs


-- 


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

[Bug libstdc++/32354] libstdc++.so.6 missing RPATH

[chapter34 at yahoo dot com]

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

Mark R. Bannister <chapter34 at yahoo dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |chapter34 at yahoo dot com

--- Comment #11 from Mark R. Bannister <chapter34 at yahoo dot com> ---
I've also hit this problem on Solaris 10 building gcc 4.8.0 and it's been
wasting an awful lot of time.  I intend to use $ORIGIN in my RPATH but could
not find a way to get an RPATH into libstdc++.  Having tried LDFLAGS, CFLAGS
and CXXFLAGS which get the RPATH into everything else ok *except* libstdc++, I
am now going to try LD_RUN_PATH as suggested in #9.

However, why has this been closed as RESOLVED INVALID?  There needs to be a way
of getting RPATHs successfully through to the built objects in a consistent and
configurable way, and we don't have that today.

Btw, re #8, see:

http://technicalprose.blogspot.co.uk/2013/06/editing-dtrpath-on-solaris-elf-objects.html