Re: libf2c/6288: libg2c.sl.0.0 and libobjc.sl.1.0 are linked to l

[law@redhat.com]

The following reply was made to PR libf2c/6288; it has been noted by GNATS.

From: law@redhat.com
To: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
Cc: gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org, dave.anglin@nrc.ca,
        mark@codesourcery.com
Subject: Re: libf2c/6288: libg2c.sl.0.0 and libobjc.sl.1.0 are linked to l 
Date: Tue, 16 Apr 2002 14:14:37 -0600

  In message <200204161724.g3GHOGYQ011996@hiauly1.hia.nrc.ca>, "John David 
 Anglin" writes:
  > > >Synopsis:       libg2c.sl.0.0 and libobjc.sl.1.0 are linked to libgcc_s.s
  > l
  > > in build directory after installation
  > 
  > The above is also true for libstdc++.sl.  The result is libraries that
  > are more or less useless unless the user manually uses chatr to enable
  > searching with SHLIB_PATH or LD_LIBRARY_PATH under hpux 10 and 11,
  > respectively.
  > 
  > Alex says that libtool isn't designed to relink unless libgcc_s.sl
  > becomes a libtool library.  I can't see that happening in the near
  > term.  Thus, the simplest solution seems to be to stop building a
  > shared libgcc under hpux 10 and 11 (32bit) until the installation
  > issues are resolved.  I don't particularly want to do this because
  > of the issues we have had in the past in linking a static version
  > of libgcc against libstdc++.sl.
  > 
  > I'm not a security expert but I think that the incorrect path
  > in the installed libraries is potentially a security issue.
  > 
  > Does anybody have any other suggestions?  I'm doing a build with
  > a patch to config.gcc to disable building libgcc_s.sl to see if
  > it impacts the testsuite results.
 Please don't unshare libgcc, it causes a set of problems with C++ that we
 really don't want to revisit.
 
 Instead we should make sure that whatever paths we need to be in the executable
 are actually in the executable.  There are flags to make that happen...  The
 right set of switches should get the behavior we desire.
 
 
 jeff