[Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
--- 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
[Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
--- 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
[Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
--- 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
[Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
--- 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
[Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
--- 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
[Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
--- 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
[Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
--- 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
[Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
--- 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
[Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
--- 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=13320action=view) patch (1 of 3) as described in comment #20 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5291
[Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
--- 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=13321action=view) patch (2 of 3) as described in comment #20 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5291
[Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
--- 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=13322action=view) patch (3 of 3) as described in comment #20 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5291
[Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
--- 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
[Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
--- 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
[Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
--- 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
[Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
--- 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
[Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
--- 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
[Bug libstdc++/5291] 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. 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
[Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
--- 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
[Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
--- 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=10459action=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
[Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
--- 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
[Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
--- 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
