Re: libf2c/6288: libg2c.sl.0.0 and libobjc.sl.1.0 are linked to libgcc_s.sl in build directory after installation

Re: libf2c/6288: libg2c.sl.0.0 and libobjc.sl.1.0 are linked to libgcc_s.sl in build directory after installation

[danglin]

Synopsis: libg2c.sl.0.0 and libobjc.sl.1.0 are linked to libgcc_s.sl in build directory after installation

Responsible-Changed-From-To: unassigned->danglin
Responsible-Changed-By: danglin
Responsible-Changed-When: Wed Apr 17 20:23:28 2002
Responsible-Changed-Why:
    Mine.
State-Changed-From-To: open->closed
State-Changed-By: danglin
State-Changed-When: Wed Apr 17 20:23:28 2002
State-Changed-Why:
    Can't duplicate problem after reinstall of gcc 3.1.  Although
    the dynamic path for libgcc_s.sl is incorrect, the embedded path is correctly set and should normally allow libgcc_s.sl to be found in the installation directory.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6288

Re: libf2c/6288: libg2c.sl.0.0 and libobjc.sl.1.0 are linked to libgcc_s.sl in build directory after installation

[Alexandre Oliva]

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

From: Alexandre Oliva <aoliva@redhat.com>
To: danglin@gcc.gnu.org
Cc: dave.anglin@nrc.ca, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
   nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: libf2c/6288: libg2c.sl.0.0 and libobjc.sl.1.0 are linked to libgcc_s.sl in build directory after installation
Date: 02 May 2002 11:20:52 -0300

 On Apr 18, 2002, danglin@gcc.gnu.org wrote:
 
 >     Can't duplicate problem after reinstall of gcc 3.1.  Although
 >     the dynamic path for libgcc_s.sl is incorrect, the embedded path
 >     is correctly set and should normally allow libgcc_s.sl to be
 >     found in the installation directory.
 
 HP-UX is a bit confusing as for shared library paths.  The location of
 a shared library at link time is stored in libraries or executables
 linked with it, as a fallback in case the library is not found
 elsewhere.
 
 Since we actually require LD_LIBRARY_PATH or equivalent (SHLIB_PATH,
 for HP-UX) for GCC's shared libraries to be usable in general, this
 should get libgcc working just fine too.
 
 -- 
 Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
 Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
 CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
 Free Software Evangelist                Professional serial bug killer

libf2c/6288: libg2c.sl.0.0 and libobjc.sl.1.0 are linked to libgcc_s.sl in build directory after installation

[dave.anglin]

>Number:         6288
>Category:       libf2c
>Synopsis:       libg2c.sl.0.0 and libobjc.sl.1.0 are linked to libgcc_s.sl in build directory after installation
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Apr 13 11:46:04 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     Dave Anglin
>Release:        gcc 3.1 (prerelease)
>Organization:
>Environment:
hppa[1.1,2.0w]-hp-hpux[10,11].*
>Description:
In the process, I discovered that libg2c.sl.0.0 and
libobjc.sl.1.0 are linked to libgcc_s.sl
in the build directory after installation:

# chatr libg2c.sl.0.0
         [...]
         internal name:
             libg2c.sl.0
         shared library list:
             dynamic   /usr/lib/libm.2
             dynamic   /usr/lib/libc.2
             dynamic   /xxx/gnu/gcc-3.1/objdir/gcc/libgcc_s.sl

The installation/build process has incorrectly linked
against libgcc_s.sl in my build directory rather than
against the newly installed version in the installation
directory.  When libgcc_s.sl is removed from the build
directory, the dynamic loader is unable to find libgcc_s.sl
and applications linked against the libraries nolonger
run.
>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: