From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23700 invoked by alias); 16 Apr 2002 20:16:34 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 23633 invoked by uid 71); 16 Apr 2002 20:16:32 -0000 Date: Tue, 16 Apr 2002 13:16:00 -0000 Message-ID: <20020416201632.23632.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: law@redhat.com Subject: Re: libf2c/6288: libg2c.sl.0.0 and libobjc.sl.1.0 are linked to l Reply-To: law@redhat.com X-SW-Source: 2002-04/txt/msg00849.txt.bz2 List-Id: The following reply was made to PR libf2c/6288; it has been noted by GNATS. From: law@redhat.com To: "John David Anglin" 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