--- 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-
--- 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 sa
--- 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 = \
--- 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
--- 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
--- 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#stat
--- 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).
-
--- 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
--- 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
--- 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
--- 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 an
--- 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 t
--- 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 l
--- 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
--- 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.
--- 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 foun
--- 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 up
--- 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
--- 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).
--- 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
-
--- 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 pr
21 matches
Mail list logo