public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: c++/10268: C++ executables fail: libstdc++.so.5 not found
@ 2003-03-31 12:16 Hallvard B Furuseth
0 siblings, 0 replies; 7+ messages in thread
From: Hallvard B Furuseth @ 2003-03-31 12:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR c++/10268; it has been noted by GNATS.
From: Hallvard B Furuseth <h.b.furuseth@usit.uio.no>
To: ehrhardt@mathematik.uni-ulm.de,
gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org,
gcc-gnats@gcc.gnu.org
Cc:
Subject: Re: c++/10268: C++ executables fail: libstdc++.so.5 not found
Date: Mon, 31 Mar 2003 12:14:10 +0200
ehrhardt@mathematik.uni-ulm.de writes:
> This behaviour is intentional. -R adds paths to the executable and
> gcc should not add system specific paths to an executable.
> You can either set LD_RUN_PATH at compile time or LD_LIBRARY_PATH
> at run time.
*What*? Why is it better to have an executable which doesn't work than
one where GCC has added a path which is needed to make it work? In
particular since the user must add the same path to make it work anyway.
If you don't want to add to the executable's path, I think you should
only build static libraries. If one configures gcc to build dynamic
libraries, add the path and warn about whatever the problem is with
adding such a path, or don't add it and give a very loud warning that
g++ will build executables that don't work.
If you don't want to do that, I it would be better to remove the
-L<path> too from g++'s defaults, at least that way the user won't think
he has built a working executable just because he compiled with standard
options and the compilation succeeded.
And document this, and how one is supposed to make it work.
Requiring users to set LD_LIBRARY_PATH at run time is a silly default,
and setting environment variables doesn't work well in Makefiles anyway,
but I suppose one could add this to Makefile:
LDFLAGS=-R`g++ -print-file-name=libstdc++.so.5 | sed 's%/[^/]*$%%'`
(Does that work if there are other libstdc++'s in the path?)
Or better, some new command which doesn't require the user to understand
sed and pipes. I've noticed there is a libgcc_s.so as well which only
seems to be used by g++, is that always in the same location as
libstdc++.so or can one need another -R for that?
BTW, can I configure gcc to put that directory in the path for g++ but
not for gcc, or edit the specs file to do so?
--
Hallvard
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: c++/10268: C++ executables fail: libstdc++.so.5 not found
@ 2003-03-31 15:29 Phil Edwards
0 siblings, 0 replies; 7+ messages in thread
From: Phil Edwards @ 2003-03-31 15:29 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR c++/10268; it has been noted by GNATS.
From: Phil Edwards <phil@jaj.com>
To: Hallvard B Furuseth <h.b.furuseth@usit.uio.no>
Cc: Christian Ehrhardt <ehrhardt@mathematik.uni-ulm.de>, gcc-bugs@gcc.gnu.org,
gcc-gnats@gcc.gnu.org
Subject: Re: c++/10268: C++ executables fail: libstdc++.so.5 not found
Date: Mon, 31 Mar 2003 10:32:46 -0500
On Mon, Mar 31, 2003 at 04:57:50PM +0200, Hallvard B Furuseth wrote:
> [I've excluded gcc-prs@gcc.gnu.org from the cc: list, since it rejects
> mail from "outsiders".]
It's a read-only address, don't feel bad. :-) It shouldn't be showing up
in the To/Cc headers at all. (It's a bug on our end.)
--
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace. We seek
not your counsel, nor your arms. Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen. - Samuel Adams
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: c++/10268: C++ executables fail: libstdc++.so.5 not found
@ 2003-03-31 15:16 Hallvard B Furuseth
0 siblings, 0 replies; 7+ messages in thread
From: Hallvard B Furuseth @ 2003-03-31 15:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR c++/10268; it has been noted by GNATS.
From: Hallvard B Furuseth <h.b.furuseth@usit.uio.no>
To: Christian Ehrhardt <ehrhardt@mathematik.uni-ulm.de>
Cc: gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: c++/10268: C++ executables fail: libstdc++.so.5 not found
Date: Mon, 31 Mar 2003 16:59:56 +0200
Christian Ehrhardt writes:
> This is even covered by the gcc FAQ at http://gcc.gnu.org/faq.html#rpath
Note: THe FAQ entry need a change: It doesn't occur only if one
configures with --enable-shared, but also if one configures without
--disable-shared.
--
Hallvard
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: c++/10268: C++ executables fail: libstdc++.so.5 not found
@ 2003-03-31 15:06 Hallvard B Furuseth
0 siblings, 0 replies; 7+ messages in thread
From: Hallvard B Furuseth @ 2003-03-31 15:06 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR c++/10268; it has been noted by GNATS.
From: Hallvard B Furuseth <h.b.furuseth@usit.uio.no>
To: Christian Ehrhardt <ehrhardt@mathematik.uni-ulm.de>
Cc: gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: c++/10268: C++ executables fail: libstdc++.so.5 not found
Date: Mon, 31 Mar 2003 16:57:50 +0200
[I've excluded gcc-prs@gcc.gnu.org from the cc: list, since it rejects
mail from "outsiders".]
Christian Ehrhardt writes:
> This is even covered by the gcc FAQ at http://gcc.gnu.org/faq.html#rpath
Oops.
>> If you don't want to add to the executable's path, I think you should
>> only build static libraries. If one configures gcc to build dynamic
>> libraries, add the path and warn about whatever the problem is with
>> adding such a path, or don't add it and give a very loud warning that
>> g++ will build executables that don't work.
>
> There is a loud warning when you install the shared libraries!
Oh. I found it in the typescript now, I think it scrolled away during
installation. Though I still think a warning at the end of configure
would be better (so it wouldn't scroll away). I think I've seen the
warning before though. I guess it just didn't occur to me that it
applied even if I didn't use the -L option myself.
Thanks.
--
Hallvard
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: c++/10268: C++ executables fail: libstdc++.so.5 not found
@ 2003-03-31 14:53 Christian Ehrhardt
0 siblings, 0 replies; 7+ messages in thread
From: Christian Ehrhardt @ 2003-03-31 14:53 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR c++/10268; it has been noted by GNATS.
From: "Christian Ehrhardt" <ehrhardt@mathematik.uni-ulm.de>
To: Hallvard B Furuseth <h.b.furuseth@usit.uio.no>
Cc: ehrhardt@mathematik.uni-ulm.de, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: c++/10268: C++ executables fail: libstdc++.so.5 not found
Date: Mon, 31 Mar 2003 16:44:45 +0200
This whole issue has been discussed many times on the gcc lists and
this is not going to change any time soon. Note that this doesn't
mean that I like the result of this discussion.
This is even covered by the gcc FAQ at http://gcc.gnu.org/faq.html#rpath
On Mon, Mar 31, 2003 at 12:14:10PM +0200, Hallvard B Furuseth wrote:
> ehrhardt@mathematik.uni-ulm.de writes:
> > This behaviour is intentional. -R adds paths to the executable and
> > gcc should not add system specific paths to an executable.
> > You can either set LD_RUN_PATH at compile time or LD_LIBRARY_PATH
> > at run time.
>
> *What*? Why is it better to have an executable which doesn't work than
> one where GCC has added a path which is needed to make it work? In
> particular since the user must add the same path to make it work anyway.
Because that path might have unexpected effects if the executable is
transfered to another machine.
> If you don't want to add to the executable's path, I think you should
> only build static libraries. If one configures gcc to build dynamic
> libraries, add the path and warn about whatever the problem is with
> adding such a path, or don't add it and give a very loud warning that
> g++ will build executables that don't work.
There is a loud warning when you install the shared libraries!
> And document this, and how one is supposed to make it work.
See the FAQ entry mentioned above.
regards Christian
--
THAT'S ALL FOLKS!
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: c++/10268: C++ executables fail: libstdc++.so.5 not found
@ 2003-03-30 17:44 ehrhardt
0 siblings, 0 replies; 7+ messages in thread
From: ehrhardt @ 2003-03-30 17:44 UTC (permalink / raw)
To: gcc-bugs, gcc-prs, h.b.furuseth, nobody
Synopsis: C++ executables fail: libstdc++.so.5 not found
State-Changed-From-To: open->closed
State-Changed-By: cae
State-Changed-When: Sun Mar 30 17:24:09 2003
State-Changed-Why:
This behaviour is intentional. -R adds paths to the executable and
gcc should not add system specific paths to an executable.
You can either set LD_RUN_PATH at compile time or LD_LIBRARY_PATH
at run time.
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10268
^ permalink raw reply [flat|nested] 7+ messages in thread
* c++/10268: C++ executables fail: libstdc++.so.5 not found
@ 2003-03-30 11:56 Hallvard B Furuseth
0 siblings, 0 replies; 7+ messages in thread
From: Hallvard B Furuseth @ 2003-03-30 11:56 UTC (permalink / raw)
To: gcc-gnats
>Number: 10268
>Category: c++
>Synopsis: C++ executables fail: libstdc++.so.5 not found
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sun Mar 30 11:46:01 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator: Hallvard B Furuseth
>Release: 3.2.2
>Organization:
>Environment:
System: SunOS bombur.uio.no 5.8 Generic_108528-13 sun4u sparc SUNW,Ultra-5_10
Architecture: sun4
host: sparc-sun-solaris2.8
build: sparc-sun-solaris2.8
target: sparc-sun-solaris2.8
configured with: ../gcc-3.2.2/configure --enable-languages=c,c++,f77 --prefix=/usit/bombur/hbf --enable-version-specific-runtime-libs --enable-threads
>Description:
C++ executables fail with
ld.so.1: ./a.out: fatal: libstdc++.so.5: open failed:
No such file or directory
>How-To-Repeat:
bash$ cat a.cc
int main(void) { return 0; }
bash$ g++ -c a.cc
bash$ g++ -v a.o
Reading specs from
/usit/bombur/hbf/lib/gcc-lib/sparc-sun-solaris2.8/3.2.2/specs
Configured with: ../gcc-3.2.2/configure --enable-languages=c,c++,f77
--prefix=/usit/bombur/hbf --enable-version-specific-runtime-libs
--enable-threads
Thread model: posix
gcc version 3.2.2
/usit/bombur/hbf/lib/gcc-lib/sparc-sun-solaris2.8/3.2.2/collect2 -V
-Y P,/usr/ccs/lib:/usr/lib
-Qy
/usit/bombur/hbf/lib/gcc-lib/sparc-sun-solaris2.8/3.2.2/crt1.o
/usit/bombur/hbf/lib/gcc-lib/sparc-sun-solaris2.8/3.2.2/crti.o
/usr/ccs/lib/values-Xa.o
/usit/bombur/hbf/lib/gcc-lib/sparc-sun-solaris2.8/3.2.2/crtbegin.o
-L/usit/bombur/hbf/lib/gcc-lib/sparc-sun-solaris2.8/3.2.2
-L/usr/ccs/bin -L/usr/ccs/lib
-L/usit/bombur/hbf/lib/gcc-lib/sparc-sun-solaris2.8/3.2.2/../../..
a.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc -lc
/usit/bombur/hbf/lib/gcc-lib/sparc-sun-solaris2.8/3.2.2/crtend.o
/usit/bombur/hbf/lib/gcc-lib/sparc-sun-solaris2.8/3.2.2/crtn.o
ld: Software Generation Utilities - Solaris-ELF (4.0)
bash$ ./a.out
ld.so.1: ./a.out: fatal: libstdc++.so.5: open failed: No such file or directory
Killed
>Fix:
Workaround:
bash$ g++ -R/usit/bombur/hbf/lib/gcc-lib/sparc-sun-solaris2.8/3.2.2 -v a.o
bash$ ./a.out
bash$
Note: I configured with --enable-version-specific-runtime-libs.
>Release-Note:
>Audit-Trail:
>Unformatted:
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2003-03-31 15:16 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-03-31 12:16 c++/10268: C++ executables fail: libstdc++.so.5 not found Hallvard B Furuseth
-- strict thread matches above, loose matches on Subject: below --
2003-03-31 15:29 Phil Edwards
2003-03-31 15:16 Hallvard B Furuseth
2003-03-31 15:06 Hallvard B Furuseth
2003-03-31 14:53 Christian Ehrhardt
2003-03-30 17:44 ehrhardt
2003-03-30 11:56 Hallvard B Furuseth
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).