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

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

[John David Anglin]

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

From: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
To: law@redhat.com
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: Wed, 17 Apr 2002 23:31:22 -0400 (EDT)

 > 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.
 
 I have closed this PR since after reinstalling gcc-3.1 under
 hppa2.0w-hp-hpux11.11 I haven't been able to duplicate the problem.  The
 embedded path is correctly set and enabled.  This should allow libgcc_s.sl
 to be located in the installation directory if it isn't found in the
 default location in the build directory.
 
 Frankly, I am puzzled but it may have just been the result of doing
 too many things at once.
 
 Dave
 -- 
 J. David Anglin                                  dave.anglin@nrc.ca
 National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

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

[law]

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
 

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

[John David Anglin]

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

From: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
To: gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org
Cc: dave.anglin@nrc.ca, law@redhat.com, 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 13:24:15 -0400 (EDT)

 > >Synopsis:       libg2c.sl.0.0 and libobjc.sl.1.0 are linked to libgcc_s.sl
 > 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.
 
 Dave
 -- 
 J. David Anglin                                  dave.anglin@nrc.ca
 National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)