NetBSD Problem Report #27775

From dillo@danbala.tuwien.ac.at  Tue Nov  2 04:10:25 2004
Return-Path: <dillo@danbala.tuwien.ac.at>
Received: from danbala.tuwien.ac.at (danbala.ifoer.tuwien.ac.at [128.130.168.64])
	by narn.netbsd.org (Postfix) with ESMTP id 8883E251F0A
	for <gnats-bugs@gnats.NetBSD.org>; Tue,  2 Nov 2004 04:10:24 +0000 (UTC)
Message-Id: <200411020410.iA24AIA16461@danbala.tuwien.ac.at>
Date: Tue, 2 Nov 2004 05:10:18 +0100 (CET)
From: dillo@NetBSD.org
Reply-To: dillo@NetBSD.org
To: gnats-bugs@gnats.NetBSD.org
Subject: programs compiled with gcc34 don't find gcc34's libraries
X-Send-Pr-Version: 3.95

>Number:         27775
>Category:       pkg
>Synopsis:       programs compiled with gcc34 don't find gcc34's libraries
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    pkg-manager
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Nov 02 04:11:00 +0000 2004
>Closed-Date:    Sat Jun 23 20:50:22 +0000 2018
>Last-Modified:  Sat Jun 23 20:50:22 +0000 2018
>Originator:     Dieter Baron
>Release:        NetBSD 2.0_BETA
>Organization:
>Environment:


System: NetBSD wintermute 2.0_BETA NetBSD 2.0_BETA (WINTERMUTE) #5: Fri Jun 18 01:19:15 MEST 2004 root@wintermute:/usr/src/sys/arch/i386/compile/WINTERMUTE i386
Architecture: i386
Machine: i386
>Description:
	gcc34 does not include a runtime library search path to
	${LOCALBASE}/gcc34/lib, where it's shared libraries reside.
	As a result, any program that needs runtime support libraries
	(e. g. C++ or Java), doesn't run unless the search path is
	added manually.
>How-To-Repeat:
	compile the following program with ${LOCALBASE}/gcc34/bin/g++:

#include <iostream>

int
main()
{
std::cout << "Hello World.\n";
}

	and see it fail with:
Shared object "libstdc++.so.6" not found
>Fix:
	Have gcc include ${LOCALBASE}/gcc34/lib in the runtime
	library search path of executables it creates.
>Release-Note:
>Audit-Trail:

From: "John R. Shannon" <shannonjr@netbsd.org>
To: dillo@netbsd.org
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: pkg/27775: programs compiled with gcc34 don't find gcc34's libraries
Date: Tue, 2 Nov 2004 10:12:36 -0700

 gcc does this on purpose. The explanation from their FAQ is as follows:

    GCC  does  not  specify  a runpath so that the dynamic linker can find
    dynamic libraries at runtime.

    The  short  explanation  is that if you always pass a -R option to the
    linker,  then  your programs become dependent on directories which may
    be NFS mounted, and programs may hang unnecessarily when an NFS server
    goes down.

    The  problem  is  not  programs that do require the directories; those
    programs  are  going  to  hang  no  matter what you do. The problem is
    programs that do not require the directories.

    SunOS  effectively always passed a -R option for every -L option; this
    was  a  bad  idea,  and  so  it was removed for Solaris. We should not
    recreate it.

    However,  if  you  feel  you  really  need such an option to be passed
    automatically  to  the  linker,  you may add it to the GCC specs file.
    This  file  can  be found in the same directory that contains cc1 (run
    gcc -print-prog-name=cc1 to find it). You may add linker flags such as
    -R  or  -rpath, depending on platform and linker, to the *link or *lib
    specs.


 On Monday 01 November 2004 09:10 pm, dillo@NetBSD.org wrote:
 > >Number:         27775
 > >Category:       pkg
 > >Synopsis:       programs compiled with gcc34 don't find gcc34's libraries
 > >Confidential:   yes
 > >Severity:       non-critical
 > >Priority:       medium
 > >Responsible:    pkg-manager
 > >State:          open
 > >Quarter:
 > >Keywords:
 > >Date-Required:
 > >Class:          sw-bug
 > >Submitter-Id:   net
 > >Arrival-Date:   Tue Nov 02 04:11:00 UTC 2004
 > >Closed-Date:
 > >Last-Modified:
 > >Originator:     Dieter Baron
 > >Release:        NetBSD 2.0_BETA
 > >Organization:
 > >Environment:
 >
 > System: NetBSD wintermute 2.0_BETA NetBSD 2.0_BETA (WINTERMUTE) #5: Fri Jun
 > 18 01:19:15 MEST 2004
 > root@wintermute:/usr/src/sys/arch/i386/compile/WINTERMUTE i386
 > Architecture: i386
 > Machine: i386
 >
 > >Description:
 >
 >  gcc34 does not include a runtime library search path to
 >  ${LOCALBASE}/gcc34/lib, where it's shared libraries reside.
 >  As a result, any program that needs runtime support libraries
 > 	(e. g. C++ or Java), doesn't run unless the search path is
 > 	added manually.
 >
 > >How-To-Repeat:
 >
 > 	compile the following program with ${LOCALBASE}/gcc34/bin/g++:
 >
 > #include <iostream>
 >
 > int
 > main()
 > {
 > std::cout << "Hello World.\n";
 > }
 >
 > 	and see it fail with:
 > Shared object "libstdc++.so.6" not found
 >
 > >Fix:
 >
 > 	Have gcc include ${LOCALBASE}/gcc34/lib in the runtime
 > 	library search path of executables it creates.
 >
 > >Release-Note:
 > >Audit-Trail:
 > >Unformatted:

 -- 

 John R. Shannon
 shannonjr@netbsd.org

From: Dieter Baron <dillo@danbala.ifoer.tuwien.ac.at>
To: "John R. Shannon" <shannonjr@netbsd.org>
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: pkg/27775: programs compiled with gcc34 don't find gcc34's libraries
Date: Thu, 4 Nov 2004 12:26:34 +0100

 hi,

 > gcc does this on purpose. The explanation from their FAQ is as follows:
 > 
 >    GCC  does  not  specify  a runpath so that the dynamic linker can find
 >    dynamic libraries at runtime.
 [...]
 >    SunOS  effectively always passed a -R option for every -L option; this
 >    was  a  bad  idea,  and  so  it was removed for Solaris. We should not
 >    recreate it.

   I accept that gcc does not record directories specified with -L as
 runtime library search path.  What I'm complaining is, that it adds
 libraries implicitly which are then not found at runtime.  The user
 should not have to know where these libraries reside, nor that they
 are needed.

 >    The  short  explanation  is that if you always pass a -R option to the
 >    linker,  then  your programs become dependent on directories which may
 >    be NFS mounted, and programs may hang unnecessarily when an NFS server
 >    goes down.
 > 
 >    The  problem  is  not  programs that do require the directories; those
 >    programs  are  going  to  hang  no  matter what you do. The problem is
 >    programs that do not require the directories.

   Every C++ program depends on libstdc++, every Java program depends
 on libgcj.  So the above problem never arises for C++ or Java
 programs.

   I would like for g++ and gcj to add ${LOCALBASE}/gcc34/lib as a
 runtime path, since it is always needed.  Why should the user have to
 find out that he has to specify -Wl,-R{$LOCALBASE}/gcc34/lib in order
 to get working programs?

 						yours,
 						dillo
Responsible-Changed-From-To: pkg-manager->shannonjr
Responsible-Changed-By: wiz@netbsd.org
Responsible-Changed-When: Thu, 17 Mar 2005 20:58:53 +0000
Responsible-Changed-Why:
Over to maintainer.


Responsible-Changed-From-To: shannonjr->joerg
Responsible-Changed-By: joerg@netbsd.org
Responsible-Changed-When: Sat, 23 Sep 2006 14:15:09 +0000
Responsible-Changed-Why:
I'll port and test the DragonFly patch.


Responsible-Changed-From-To: joerg->shannonjr
Responsible-Changed-By: joerg@NetBSD.org
Responsible-Changed-When: Wed, 21 May 2008 21:44:20 +0000
Responsible-Changed-Why:
Never found the time, so assign back to maintainer.


Responsible-Changed-From-To: shannonjr->pkg-manager
Responsible-Changed-By: wiz@NetBSD.org
Responsible-Changed-When: Fri, 01 Feb 2013 22:56:44 +0000
Responsible-Changed-Why:
Back to role account.


State-Changed-From-To: open->closed
State-Changed-By: maya@NetBSD.org
State-Changed-When: Sat, 23 Jun 2018 20:50:22 +0000
State-Changed-Why:
Not a problem with newer versions of gcc in pkgsrc. Not going to check very old gcc if it does this too, because it needs work to build at all
fly@planets ~> /usr/pkg/gcc8/bin/g++ t_cabsl.cxx
fly@planets ~> ldd a.out
a.out:
	-lstdc++.7 => /usr/pkg/gcc8//lib/./libstdc++.so.7
	-lm.0 => /usr/lib/libm.so.0
	-lc.12 => /usr/lib/libc.so.12
	-lgcc_s.1 => /usr/pkg/gcc8//lib/./libgcc_s.so.1



>Unformatted:
 >Quarter:        
 >Keywords:       
 >Date-Required:  

Home	PR Database Search