This is GCC Bugzilla
This is GCC Bugzilla Version 2.20+
View Bug Activity | Format For Printing | Clone This Bug
The value of dependency_libs in libstdc++.la contains -L options that refer to the build directory. These are coming from libstdcxx_flags in the toplevel configure.in file. An installed libtool link file must never contain a reference to the build or source directory. Alexandre Oliva commented on this report: > It's a problem in libtool that has been known for a while, and > already brought in the mailing lists at least twice. It's mostly > harmless, and no fix is available, I'm afraid. It might be harmless but rather annoying since linker command lines get longer and longer :-( Andreas Jaeger Release: 3.1 20020105 (experimental) Environment: System: Linux sykes 2.4.16-SMP #1 SMP Wed Jan 2 19:54:14 GMT 2002 ia64 unknown Architecture: ia64 host: ia64-unknown-linux-gnu build: ia64-unknown-linux-gnu target: ia64-unknown-linux-gnu configured with: /cvs/gcc/configure ia64-linux --prefix=/usr/local/ia64-linux --enable-shared --enable-threads --with-system-zlib : (reconfigured) : (reconfigured)
State-Changed-From-To: open->suspended State-Changed-Why: 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. There doesn't seem to be a libtool bug database, so I can't point to an official report anywhere.
Responsible-Changed-From-To: unassigned->aoliva Responsible-Changed-Why: Yours......
*** Bug 3525 has been marked as a duplicate of this bug. ***
*** Bug 11153 has been marked as a duplicate of this bug. ***
*** Bug 15246 has been marked as a duplicate of this bug. ***
> 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.
> 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.
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.
*** Bug 17366 has been marked as a duplicate of this bug. ***
(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.
*** Bug 19962 has been marked as a duplicate of this bug. ***
Created an attachment (id=10459) [edit] 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
*** Bug 26472 has been marked as a duplicate of this bug. ***
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
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
(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
*** Bug 30861 has been marked as a duplicate of this bug. ***
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?
(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.
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
Created an attachment (id=13320) [edit] patch (1 of 3) as described in comment #20
Created an attachment (id=13321) [edit] patch (2 of 3) as described in comment #20
Created an attachment (id=13322) [edit] patch (3 of 3) as described in comment #20
> 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).
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
Hi Paolo, any chance you can comment on this PR / review the patches in Comments 20 - 23 ? Thanks in advance.
It seems to me that the "old" RAW_CXX_FOR_TARGET is unused after the patch. Can you confirm?
(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.
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.
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.