* [Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
[not found] <20020106074600.5291.schwab@suse.de>
@ 2003-07-22 2:59 ` pinskia at physics dot uc dot edu
2003-08-06 0:46 ` pinskia at physics dot uc dot edu
` (6 subsequent siblings)
7 siblings, 0 replies; 28+ messages in thread
From: pinskia at physics dot uc dot edu @ 2003-07-22 2:59 UTC (permalink / raw)
To: gcc-bugs
PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5291
pinskia at physics dot uc dot edu changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |peb at mppmu dot mpg dot de
------- Additional Comments From pinskia at physics dot uc dot edu 2003-07-22 02:59 -------
*** Bug 11153 has been marked as a duplicate of this bug. ***
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
[not found] <20020106074600.5291.schwab@suse.de>
2003-07-22 2:59 ` [Bug libstdc++/5291] Bad reference to build directory in libstdc++.la pinskia at physics dot uc dot edu
@ 2003-08-06 0:46 ` pinskia at physics dot uc dot edu
2004-05-01 21:42 ` pinskia at gcc dot gnu dot org
` (5 subsequent siblings)
7 siblings, 0 replies; 28+ messages in thread
From: pinskia at physics dot uc dot edu @ 2003-08-06 0:46 UTC (permalink / raw)
To: gcc-bugs
PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5291
pinskia at physics dot uc dot edu changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|critical |normal
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
[not found] <20020106074600.5291.schwab@suse.de>
2003-07-22 2:59 ` [Bug libstdc++/5291] Bad reference to build directory in libstdc++.la pinskia at physics dot uc dot edu
2003-08-06 0:46 ` pinskia at physics dot uc dot edu
@ 2004-05-01 21:42 ` pinskia at gcc dot gnu dot org
2004-05-02 17:01 ` danglin at gcc dot gnu dot org
` (4 subsequent siblings)
7 siblings, 0 replies; 28+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-05-01 21:42 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pinskia at gcc dot gnu dot org 2004-05-01 21:42 -------
*** Bug 15246 has been marked as a duplicate of this bug. ***
--
What |Removed |Added
----------------------------------------------------------------------------
CC| |danglin at gcc dot gnu dot
| |org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5291
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
[not found] <20020106074600.5291.schwab@suse.de>
` (2 preceding siblings ...)
2004-05-01 21:42 ` pinskia at gcc dot gnu dot org
@ 2004-05-02 17:01 ` danglin at gcc dot gnu dot org
2004-05-02 17:13 ` danglin at gcc dot gnu dot org
` (3 subsequent siblings)
7 siblings, 0 replies; 28+ messages in thread
From: danglin at gcc dot gnu dot org @ 2004-05-02 17:01 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From danglin at gcc dot gnu dot org 2004-05-02 17:01 -------
> It might be harmless but rather annoying since linker command lines
> get longer and longer :-(
It's not harmless on the PA. If other libraries are built when the
build directory contains libraries, you can end up with a hardcoded
dependence on one or more libraries in the build directory. In the
case that I saw, it was to libgcc_s.sl.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5291
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
[not found] <20020106074600.5291.schwab@suse.de>
` (3 preceding siblings ...)
2004-05-02 17:01 ` danglin at gcc dot gnu dot org
@ 2004-05-02 17:13 ` danglin at gcc dot gnu dot org
2004-05-03 4:18 ` aoliva at gcc dot gnu dot org
` (2 subsequent siblings)
7 siblings, 0 replies; 28+ messages in thread
From: danglin at gcc dot gnu dot org @ 2004-05-02 17:13 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From danglin at gcc dot gnu dot org 2004-05-02 17:13 -------
> This is a known libtool bug. There's nothing the library
> can do about it. I'm not closing this PR now because it
> does continue to still be a problem.
I think for library installations we need to use libtool configured
with the installed version of gcc, or adjust the "-B' options so that
they don't reference the build directory.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5291
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
[not found] <20020106074600.5291.schwab@suse.de>
` (4 preceding siblings ...)
2004-05-02 17:13 ` danglin at gcc dot gnu dot org
@ 2004-05-03 4:18 ` aoliva at gcc dot gnu dot org
2004-09-09 2:32 ` pinskia at gcc dot gnu dot org
2005-07-01 16:24 ` peb at mppmu dot mpg dot de
7 siblings, 0 replies; 28+ messages in thread
From: aoliva at gcc dot gnu dot org @ 2004-05-03 4:18 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From aoliva at gcc dot gnu dot org 2004-05-03 04:18 -------
Note that, on PA, the linker does indeed annotate an executable with the
location in which it found the library, but that's just a cache, it doesn't
require the library to be there in order to function. Libtool knows about that,
and does the right thing when linking with a libtool library, but libgcc_s isn't
a libtool library, so libtool can't do much.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5291
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
[not found] <20020106074600.5291.schwab@suse.de>
` (5 preceding siblings ...)
2004-05-03 4:18 ` aoliva at gcc dot gnu dot org
@ 2004-09-09 2:32 ` pinskia at gcc dot gnu dot org
2005-07-01 16:24 ` peb at mppmu dot mpg dot de
7 siblings, 0 replies; 28+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-09-09 2:32 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pinskia at gcc dot gnu dot org 2004-09-09 02:32 -------
*** Bug 17366 has been marked as a duplicate of this bug. ***
--
What |Removed |Added
----------------------------------------------------------------------------
CC| |bfriesen at simple dot
| |dallas dot tx dot us
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5291
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
[not found] <20020106074600.5291.schwab@suse.de>
` (6 preceding siblings ...)
2004-09-09 2:32 ` pinskia at gcc dot gnu dot org
@ 2005-07-01 16:24 ` peb at mppmu dot mpg dot de
7 siblings, 0 replies; 28+ messages in thread
From: peb at mppmu dot mpg dot de @ 2005-07-01 16:24 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From peb at mppmu dot mpg dot de 2005-07-01 16:24 -------
(In reply to comment #7)
> > This is a known libtool bug. There's nothing the library
> > can do about it. I'm not closing this PR now because it
> > does continue to still be a problem.
This bug is still present in gcc-4.0.0 !!
Linker lines getting longer and longer is one problem. In addition a reference
to an unavailable NFS server can cause serious and mysterious timeouts.
I strongly suspect this is NOT a libtool problem, but rather a problem with
either the libtool version gcc is using or with the way is is used. I never saw
similar problems with genuine libtool libraries.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5291
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
[not found] <bug-5291-50@http.gcc.gnu.org/bugzilla/>
@ 2005-11-04 1:13 ` pinskia at gcc dot gnu dot org
2005-12-12 16:54 ` Ralf dot Wildenhues at gmx dot de
` (18 subsequent siblings)
19 siblings, 0 replies; 28+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-11-04 1:13 UTC (permalink / raw)
To: gcc-bugs
------- Comment #11 from pinskia at gcc dot gnu dot org 2005-11-04 01:13 -------
*** Bug 19962 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |quanah at stanford dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5291
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
[not found] <bug-5291-50@http.gcc.gnu.org/bugzilla/>
2005-11-04 1:13 ` pinskia at gcc dot gnu dot org
@ 2005-12-12 16:54 ` Ralf dot Wildenhues at gmx dot de
2006-02-26 5:56 ` pinskia at gcc dot gnu dot org
` (17 subsequent siblings)
19 siblings, 0 replies; 28+ messages in thread
From: Ralf dot Wildenhues at gmx dot de @ 2005-12-12 16:54 UTC (permalink / raw)
To: gcc-bugs
------- Comment #12 from Ralf dot Wildenhues at gmx dot de 2005-12-12 16:54 -------
Created an attachment (id=10459)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10459&action=view)
quick hack to fix #5291
Here's a dirty hack to fix the installed .la files (regenerated files not
shown).
I can provide patches against classpath and libltdl as well, if this one is
deemed ok.
I do not intend to put it in upstream Libtool quite like this, but I do intend
to suggest a cleaned up version there eventually.
Cheers,
Ralf
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5291
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
[not found] <bug-5291-50@http.gcc.gnu.org/bugzilla/>
2005-11-04 1:13 ` pinskia at gcc dot gnu dot org
2005-12-12 16:54 ` Ralf dot Wildenhues at gmx dot de
@ 2006-02-26 5:56 ` pinskia at gcc dot gnu dot org
2006-02-27 22:29 ` quanah at stanford dot edu
` (16 subsequent siblings)
19 siblings, 0 replies; 28+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2006-02-26 5:56 UTC (permalink / raw)
To: gcc-bugs
------- Comment #13 from pinskia at gcc dot gnu dot org 2006-02-26 02:58 -------
*** Bug 26472 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5291
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
[not found] <bug-5291-50@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2006-02-26 5:56 ` pinskia at gcc dot gnu dot org
@ 2006-02-27 22:29 ` quanah at stanford dot edu
2006-02-28 16:00 ` dave at hiauly1 dot hia dot nrc dot ca
` (15 subsequent siblings)
19 siblings, 0 replies; 28+ messages in thread
From: quanah at stanford dot edu @ 2006-02-27 22:29 UTC (permalink / raw)
To: gcc-bugs
------- Comment #14 from quanah at stanford dot edu 2006-02-27 22:19 -------
I've tried the patch suggested in this bug. However, I found that it does
*not* fix all the issues. For example, here is the result of my libstdc++.la
file with the patch applied:
# Libraries that this one depends upon.
dependency_libs='
-L/afs/ir/src/pubsw/languages/gcc-build/@sys/x86_64-unknown-linux-gnu/libstdc++-v3/src
-L/afs/ir/src/pubsw/languages/gcc-build/@sys/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-lm -lm -lm -L/afs/ir/src/pubsw/languages/gcc-build/@sys/gcc
-L/usr/pubsw/lib/gcc/x86_64-unknown-linux-gnu/4.0.2 -L/usr/local/lib
-L/usr/pubsw/lib -L/lib/../lib64 -L/usr/lib/../lib64 -lgcc_s -lc -lgcc_s -lm
-lgcc_s -lc -lgcc_s'
As you can see, there are still *three* references to the build location.
Also, there are an amazing number of -lm's and -lgcc_s's that are unnecessary.
What I expect this to look like is simply:
dependency_libs=' -lm -L/usr/pubsw/lib -lgcc_s'
because, quite frankly, that is all that is necessary.
--Quanah
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5291
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
[not found] <bug-5291-50@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2006-02-27 22:29 ` quanah at stanford dot edu
@ 2006-02-28 16:00 ` dave at hiauly1 dot hia dot nrc dot ca
2006-02-28 16:53 ` Ralf dot Wildenhues at gmx dot de
` (14 subsequent siblings)
19 siblings, 0 replies; 28+ messages in thread
From: dave at hiauly1 dot hia dot nrc dot ca @ 2006-02-28 16:00 UTC (permalink / raw)
To: gcc-bugs
------- Comment #15 from dave at hiauly1 dot hia dot nrc dot ca 2006-02-28 15:59 -------
Subject: Re: Bad reference to build directory in libstdc++.la
> ------- Comment #14 from quanah at stanford dot edu 2006-02-27 22:19 -------
> I've tried the patch suggested in this bug. However, I found that it does
> *not* fix all the issues. For example, here is the result of my libstdc++.la
> file with the patch applied:
>
> # Libraries that this one depends upon.
> dependency_libs='
> -L/afs/ir/src/pubsw/languages/gcc-build/@sys/x86_64-unknown-linux-gnu/libstdc++-v3/src
> -L/afs/ir/src/pubsw/languages/gcc-build/@sys/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
> -lm -lm -lm -L/afs/ir/src/pubsw/languages/gcc-build/@sys/gcc
> -L/usr/pubsw/lib/gcc/x86_64-unknown-linux-gnu/4.0.2 -L/usr/local/lib
> -L/usr/pubsw/lib -L/lib/../lib64 -L/usr/lib/../lib64 -lgcc_s -lc -lgcc_s -lm
> -lgcc_s -lc -lgcc_s'
>
>
> As you can see, there are still *three* references to the build location.
I see the same thing without the patch in the installed libstdc++.la.
The real kicker is that the -L's for the build directory come before
the -L's for the install directory. For an install, the order should
be reveresed.
> Also, there are an amazing number of -lm's and -lgcc_s's that are unnecessary.
>
> What I expect this to look like is simply:
>
> dependency_libs=' -lm -L/usr/pubsw/lib -lgcc_s'
>
> because, quite frankly, that is all that is necessary.
It's my understanding that the extra -lm's and -lgcc_s's are added to
handle cyclical dependencies. These may not be present on all systems.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5291
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
[not found] <bug-5291-50@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2006-02-28 16:00 ` dave at hiauly1 dot hia dot nrc dot ca
@ 2006-02-28 16:53 ` Ralf dot Wildenhues at gmx dot de
2007-02-19 16:42 ` schwab at suse dot de
` (13 subsequent siblings)
19 siblings, 0 replies; 28+ messages in thread
From: Ralf dot Wildenhues at gmx dot de @ 2006-02-28 16:53 UTC (permalink / raw)
To: gcc-bugs
------- Comment #16 from Ralf dot Wildenhues at gmx dot de 2006-02-28 16:29 -------
(In reply to comment #15)
>
> I see the same thing without the patch in the installed libstdc++.la.
> The real kicker is that the -L's for the build directory come before
> the -L's for the install directory. For an install, the order should
> be reveresed.
No. The link paths to the build tree should not be present at all.
> > Also, there are an amazing number of -lm's and -lgcc_s's that are unnecessary.
> It's my understanding that the extra -lm's and -lgcc_s's are added to
> handle cyclical dependencies. These may not be present on all systems.
Correct on both accounts. The repetitions are harmless as long as they
do not pose a line length issue. I believe a newer Libtool should produce
less of those. But it will (not yet) fix the build tree references issue.
Cheers,
Ralf
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5291
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
[not found] <bug-5291-50@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2006-02-28 16:53 ` Ralf dot Wildenhues at gmx dot de
@ 2007-02-19 16:42 ` schwab at suse dot de
2007-02-22 8:58 ` peb at mppmu dot mpg dot de
` (12 subsequent siblings)
19 siblings, 0 replies; 28+ messages in thread
From: schwab at suse dot de @ 2007-02-19 16:42 UTC (permalink / raw)
To: gcc-bugs
------- Comment #17 from schwab at suse dot de 2007-02-19 16:42 -------
*** Bug 30861 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5291
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
[not found] <bug-5291-50@http.gcc.gnu.org/bugzilla/>
` (6 preceding siblings ...)
2007-02-19 16:42 ` schwab at suse dot de
@ 2007-02-22 8:58 ` peb at mppmu dot mpg dot de
2007-02-22 15:59 ` bfriesen at simple dot dallas dot tx dot us
` (11 subsequent siblings)
19 siblings, 0 replies; 28+ messages in thread
From: peb at mppmu dot mpg dot de @ 2007-02-22 8:58 UTC (permalink / raw)
To: gcc-bugs
------- Comment #18 from peb at mppmu dot mpg dot de 2007-02-22 08:58 -------
I have tried to analyze the cause of the -L flags passed to libtool when
linking libsupc++ and libstdc++ and found these two:
(1) explicit flags in the top-level RAW_CXX_FOR_TARGET passed as CXX to the
libstdc++ and libjava modules, and
(2) flags implicitly added by the GCC-modified "libtool --tag CXX --mode=link"
for all directories in the compiler search path. This part is easily corrected
by instead using "--tag CC" when linking libraries.
I'd like to try to fix all this, but in order to do so I need some additional
info. As far as I can see there are in principle three ways to build libstdc++:
(A) as part of building GCC (with language c++),
(B) independently with a prebuilt g++, or
(C) independently with a non-GCC compiler.
I think there is an obvious way to handle issue (1) above in case (A), but
cases (B) and in particular (C) may pose additional problems.
Question: are the possibilities (B) and (C) still viable?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5291
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
[not found] <bug-5291-50@http.gcc.gnu.org/bugzilla/>
` (7 preceding siblings ...)
2007-02-22 8:58 ` peb at mppmu dot mpg dot de
@ 2007-02-22 15:59 ` bfriesen at simple dot dallas dot tx dot us
2007-04-03 9:24 ` peb at mppmu dot mpg dot de
` (10 subsequent siblings)
19 siblings, 0 replies; 28+ messages in thread
From: bfriesen at simple dot dallas dot tx dot us @ 2007-02-22 15:59 UTC (permalink / raw)
To: gcc-bugs
------- Comment #19 from bfriesen at simple dot dallas dot tx dot us 2007-02-22 15:58 -------
(In reply to comment #8)
> Note that, on PA, the linker does indeed annotate an executable with the
> location in which it found the library, but that's just a cache, it doesn't
> require the library to be there in order to function. Libtool knows about that,
> and does the right thing when linking with a libtool library, but libgcc_s isn't
> a libtool library, so libtool can't do much.
It seems to me that on systems which encode the default library search path,
this behavior becomes a security weakness associated with the installed
library. If the GCC build directory is not secure in that it can't be
re-created by another party, then applications searching for libraries in the
build tree become subject to trojan horse type attacks. This is particularly
the case when GCC is built under /tmp (as some people do) since once the tree
has been removed, any other user on the system may create the necessary paths.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5291
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
[not found] <bug-5291-50@http.gcc.gnu.org/bugzilla/>
` (8 preceding siblings ...)
2007-02-22 15:59 ` bfriesen at simple dot dallas dot tx dot us
@ 2007-04-03 9:24 ` peb at mppmu dot mpg dot de
2007-04-03 9:27 ` peb at mppmu dot mpg dot de
` (9 subsequent siblings)
19 siblings, 0 replies; 28+ messages in thread
From: peb at mppmu dot mpg dot de @ 2007-04-03 9:24 UTC (permalink / raw)
To: gcc-bugs
------- Comment #20 from peb at mppmu dot mpg dot de 2007-04-03 10:24 -------
After some investigation I found that the problem of libtool & build paths has
three aspects:
(1) Build paths stored in installed c++ libraries (libstdc++.la and
libsupc++.la) and then propagated to other libraries and possibly as
rpath/runpath into binaries
(2) Build paths stored in installed java libraries (libgij.la)
(3) Missing LD_LIBRARY_PATH when running gcj-dbtool to produce classmap.db
(this may fail resulting in an empty classmap.db file)
================
(1) and (2) are due to
(A) explicit -L's when building libraries or executables
(B) implicit -L's due to ltcf-cxx.sh when building libraries
================
For (3) gcj-bdtool (and others) should use some run-time environment as used
for the test suite.
================
Attached are three patches addressing (A) and (B), i.e., (1) and (2) without
making (3) any worse than at present. I have successfully tested them in a
bootstrap build for i686-linux-gnu as well as x86_64-linux-gnu but more testing
would certainly be required. Here a short description:
1. patch-03-libstdc++-lt-paths-root
introduces a new make variable RAW_CXX_FOR_TARGET_LIB (as RAW_CXX_FOR_TARGET
but without explicit -L's) in the toplevel Makefile, to be passed as
CXX_FOR_TARGET_LIB to the libstdc++ and libjava modules.
2. patch-03-libstdc++-lt-paths-libstdc++
Initialize CXX_FOR_LIB from CXX_FOR_TARGET_LIB (as passed from toplevel) and
use it to build libraries.
Replace --tag CXX by --tag CC when building libraries.
3. patch-03-libstdc++-lt-paths-libjava
Initialize CXX_FOR_LIB as above
Replace --tag CXX as above
Replace dependencies, e.g., -L$(here)/.libs libgcj.la by libgcj.la when
building libgij
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5291
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
[not found] <bug-5291-50@http.gcc.gnu.org/bugzilla/>
` (9 preceding siblings ...)
2007-04-03 9:24 ` peb at mppmu dot mpg dot de
@ 2007-04-03 9:27 ` peb at mppmu dot mpg dot de
2007-04-03 9:28 ` peb at mppmu dot mpg dot de
` (8 subsequent siblings)
19 siblings, 0 replies; 28+ messages in thread
From: peb at mppmu dot mpg dot de @ 2007-04-03 9:27 UTC (permalink / raw)
To: gcc-bugs
------- Comment #21 from peb at mppmu dot mpg dot de 2007-04-03 10:27 -------
Created an attachment (id=13320)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13320&action=view)
patch (1 of 3) as described in comment #20
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5291
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
[not found] <bug-5291-50@http.gcc.gnu.org/bugzilla/>
` (10 preceding siblings ...)
2007-04-03 9:27 ` peb at mppmu dot mpg dot de
@ 2007-04-03 9:28 ` peb at mppmu dot mpg dot de
2007-04-03 9:29 ` peb at mppmu dot mpg dot de
` (7 subsequent siblings)
19 siblings, 0 replies; 28+ messages in thread
From: peb at mppmu dot mpg dot de @ 2007-04-03 9:28 UTC (permalink / raw)
To: gcc-bugs
------- Comment #22 from peb at mppmu dot mpg dot de 2007-04-03 10:28 -------
Created an attachment (id=13321)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13321&action=view)
patch (2 of 3) as described in comment #20
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5291
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
[not found] <bug-5291-50@http.gcc.gnu.org/bugzilla/>
` (11 preceding siblings ...)
2007-04-03 9:28 ` peb at mppmu dot mpg dot de
@ 2007-04-03 9:29 ` peb at mppmu dot mpg dot de
2007-10-23 19:11 ` geir at cray dot com
` (6 subsequent siblings)
19 siblings, 0 replies; 28+ messages in thread
From: peb at mppmu dot mpg dot de @ 2007-04-03 9:29 UTC (permalink / raw)
To: gcc-bugs
------- Comment #23 from peb at mppmu dot mpg dot de 2007-04-03 10:29 -------
Created an attachment (id=13322)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13322&action=view)
patch (3 of 3) as described in comment #20
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5291
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
[not found] <bug-5291-50@http.gcc.gnu.org/bugzilla/>
` (12 preceding siblings ...)
2007-04-03 9:29 ` peb at mppmu dot mpg dot de
@ 2007-10-23 19:11 ` geir at cray dot com
2007-10-23 20:11 ` dave at hiauly1 dot hia dot nrc dot ca
` (5 subsequent siblings)
19 siblings, 0 replies; 28+ messages in thread
From: geir at cray dot com @ 2007-10-23 19:11 UTC (permalink / raw)
To: gcc-bugs
------- Comment #24 from geir at cray dot com 2007-10-23 19:11 -------
> State-Changed-From-To: open->suspended
What is the status of this bug? Will the proposed patches be implemented?
(Note: http://gcc.gnu.org/bugzilla/page.cgi?id=fields.html#status does not
describe "SUSPENDED" status).
--
geir at cray dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |geir at cray dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5291
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
[not found] <bug-5291-50@http.gcc.gnu.org/bugzilla/>
` (13 preceding siblings ...)
2007-10-23 19:11 ` geir at cray dot com
@ 2007-10-23 20:11 ` dave at hiauly1 dot hia dot nrc dot ca
2007-12-01 15:00 ` pcarlini at suse dot de
` (4 subsequent siblings)
19 siblings, 0 replies; 28+ messages in thread
From: dave at hiauly1 dot hia dot nrc dot ca @ 2007-10-23 20:11 UTC (permalink / raw)
To: gcc-bugs
------- Comment #25 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-23 20:11 -------
Subject: Re: Bad reference to build directory in libstdc++.la
> What is the status of this bug? Will the proposed patches be implemented?
> (Note: http://gcc.gnu.org/bugzilla/page.cgi?id=fields.html#status does not
> describe "SUSPENDED" status).
Comment #1 appears incorrect given the proposed patches, so I believe
the bug should be reopened.
The patches need submission to gcc-patches for review.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5291
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
[not found] <bug-5291-50@http.gcc.gnu.org/bugzilla/>
` (14 preceding siblings ...)
2007-10-23 20:11 ` dave at hiauly1 dot hia dot nrc dot ca
@ 2007-12-01 15:00 ` pcarlini at suse dot de
2007-12-03 10:18 ` bonzini at gnu dot org
` (3 subsequent siblings)
19 siblings, 0 replies; 28+ messages in thread
From: pcarlini at suse dot de @ 2007-12-01 15:00 UTC (permalink / raw)
To: gcc-bugs
------- Comment #26 from pcarlini at suse dot de 2007-12-01 15:00 -------
Hi Paolo, any chance you can comment on this PR / review the patches in
Comments 20 - 23 ? Thanks in advance.
--
pcarlini at suse dot de changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bonzini at gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5291
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
[not found] <bug-5291-50@http.gcc.gnu.org/bugzilla/>
` (15 preceding siblings ...)
2007-12-01 15:00 ` pcarlini at suse dot de
@ 2007-12-03 10:18 ` bonzini at gnu dot org
2007-12-03 12:57 ` peb at mppmu dot mpg dot de
` (2 subsequent siblings)
19 siblings, 0 replies; 28+ messages in thread
From: bonzini at gnu dot org @ 2007-12-03 10:18 UTC (permalink / raw)
To: gcc-bugs
------- Comment #27 from bonzini at gnu dot org 2007-12-03 10:17 -------
It seems to me that the "old" RAW_CXX_FOR_TARGET is unused after the patch.
Can you confirm?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5291
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
[not found] <bug-5291-50@http.gcc.gnu.org/bugzilla/>
` (16 preceding siblings ...)
2007-12-03 10:18 ` bonzini at gnu dot org
@ 2007-12-03 12:57 ` peb at mppmu dot mpg dot de
2007-12-03 13:18 ` bonzini at gnu dot org
2009-01-26 23:31 ` bkoz at gcc dot gnu dot org
19 siblings, 0 replies; 28+ messages in thread
From: peb at mppmu dot mpg dot de @ 2007-12-03 12:57 UTC (permalink / raw)
To: gcc-bugs
------- Comment #28 from peb at mppmu dot mpg dot de 2007-12-03 12:57 -------
(In reply to comment #27)
> It seems to me that the "old" RAW_CXX_FOR_TARGET is unused after the patch.
> Can you confirm?
>
I don't think so. The toplevel Makefile.in contains the lines
RAW_CXX_TARGET_EXPORTS = \
CXX_FOR_TARGET="$(RAW_CXX_FOR_TARGET)"; export CXX_FOR_TARGET; \
CXX="$(RAW_CXX_FOR_TARGET)"; export CXX;
and the exported values of CXX_FOR_TARGET and CXX are subsequently used in the
libstdc++-v3 and libjava subdirs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5291
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
[not found] <bug-5291-50@http.gcc.gnu.org/bugzilla/>
` (17 preceding siblings ...)
2007-12-03 12:57 ` peb at mppmu dot mpg dot de
@ 2007-12-03 13:18 ` bonzini at gnu dot org
2009-01-26 23:31 ` bkoz at gcc dot gnu dot org
19 siblings, 0 replies; 28+ messages in thread
From: bonzini at gnu dot org @ 2007-12-03 13:18 UTC (permalink / raw)
To: gcc-bugs
------- Comment #29 from bonzini at gnu dot org 2007-12-03 13:17 -------
It might be me, but I cannot see when they are used. Or better, yes, they are
used in LTCXXCOMPILE but there a few -L... switches shouldn't make any
difference, so you could use CXX_FOR_LIB also in LTCXXCOMPILE (and the same
holds for generation of PCH files). At this point, $(CXX) would be unused, and
you can simplify things a lot.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5291
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
[not found] <bug-5291-50@http.gcc.gnu.org/bugzilla/>
` (18 preceding siblings ...)
2007-12-03 13:18 ` bonzini at gnu dot org
@ 2009-01-26 23:31 ` bkoz at gcc dot gnu dot org
19 siblings, 0 replies; 28+ messages in thread
From: bkoz at gcc dot gnu dot org @ 2009-01-26 23:31 UTC (permalink / raw)
To: gcc-bugs
------- Comment #30 from bkoz at gcc dot gnu dot org 2009-01-26 23:31 -------
This appears to have been fixed in the gcc-4.3.0 time frame. At least,
gcc-4.2.4 has:
dependency_libs='
-L/mnt/share/bld/gcc-4.2.4/x86_64-unknown-linux-gnu/libstdc++-
v3/src
-L/mnt/share/bld/gcc-4.2.4/x86_64-unknown-linux-gnu/libstdc++-v3/src/.lib
s -lm -lm -lm -L/mnt/share/bld/gcc-4.2.4/./gcc -L/lib/../lib64
-L/usr/lib/../lib
64 -lgcc_s -lc -lgcc_s -lm -lgcc_s -lc -lgcc_s '
while gcc-4.3.x/4.4.x/trunk have:
dependency_libs=' -lm'
So, I'm changing to "FIXED" with a target milestone of 4.3.0.
--
bkoz at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|SUSPENDED |RESOLVED
Resolution| |FIXED
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5291
^ permalink raw reply [flat|nested] 28+ messages in thread