[Bug libstdc++/5291] Bad reference to build directory in libstdc++.la

[Bug libstdc++/5291] Bad reference to build directory in libstdc++.la

[pinskia at physics dot uc dot edu]

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. ***

[Bug libstdc++/5291] Bad reference to build directory in libstdc++.la

[pinskia at physics dot uc dot edu]

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

[Bug libstdc++/5291] Bad reference to build directory in libstdc++.la

[pinskia at gcc dot gnu dot org]

------- 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

[Bug libstdc++/5291] Bad reference to build directory in libstdc++.la

[danglin at gcc dot gnu dot org]

------- 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

[Bug libstdc++/5291] Bad reference to build directory in libstdc++.la

[danglin at gcc dot gnu dot org]

------- 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

[Bug libstdc++/5291] Bad reference to build directory in libstdc++.la

[aoliva at gcc dot gnu dot org]

------- 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

[Bug libstdc++/5291] Bad reference to build directory in libstdc++.la

[pinskia at gcc dot gnu dot org]

------- 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

[Bug libstdc++/5291] Bad reference to build directory in libstdc++.la

[peb at mppmu dot mpg dot de]

------- 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

[Bug libstdc++/5291] Bad reference to build directory in libstdc++.la

[bkoz at gcc dot gnu dot org]

------- 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

[bonzini at gnu dot org]

------- 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

[peb at mppmu dot mpg dot de]

------- 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

[bonzini at gnu dot org]

------- 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

[pcarlini at suse dot de]

------- 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

[dave at hiauly1 dot hia dot nrc dot ca]

------- 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

[geir at cray dot com]

------- 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

[peb at mppmu dot mpg dot de]

------- 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

[Bug libstdc++/5291] Bad reference to build directory in libstdc++.la

[peb at mppmu dot mpg dot de]

------- 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

[Bug libstdc++/5291] Bad reference to build directory in libstdc++.la

[peb at mppmu dot mpg dot de]

------- 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

[Bug libstdc++/5291] Bad reference to build directory in libstdc++.la

[peb at mppmu dot mpg dot de]

------- 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

[bfriesen at simple dot dallas dot tx dot us]

------- 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

[peb at mppmu dot mpg dot de]

------- 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

[schwab at suse dot de]

------- 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

[Ralf dot Wildenhues at gmx dot de]

------- 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

[dave at hiauly1 dot hia dot nrc dot ca]

------- 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

[quanah at stanford dot edu]

------- 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

[pinskia at gcc dot gnu dot org]

------- 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

[Ralf dot Wildenhues at gmx dot de]

------- 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

[Bug libstdc++/5291] Bad reference to build directory in libstdc++.la

[pinskia at gcc dot gnu dot org]

------- 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