This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libgcj/17311] Wrong libgcc_s.so.1 is used by lt-gij
- From: "Ralf dot Wildenhues at gmx dot de" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 7 Feb 2006 16:28:06 -0000
- Subject: [Bug libgcj/17311] Wrong libgcc_s.so.1 is used by lt-gij
- References: <bug-17311-682@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #19 from Ralf dot Wildenhues at gmx dot de 2006-02-07 16:28 -------
(In reply to comment #18)
> Why do I want
>
> [hjl@gnu-13 gcc]$ readelf -d /usr/gcc-4.2/bin/gij | grep RPATH
> 0x000000000000000f (RPATH) Library rpath:
> /export/build/gnu/gcc/build-x86_64-linux/gcc
> 0x000000000000000f (RPATH) Library rpath:
> [/usr/gcc-4.2/lib/../lib64]
> [hjl@gnu-13 gcc]$
>
> It may cause more problems than it solves.
Certainly, that's a bad bug and has to be avoided at all
(the fact that this may not work correctly now is clear:
libtool does not yet fully support what I outlined).
Where was I talking about the desire to have run paths
in *installed programs* pointing *to the build tree* though?
Maybe my notation was bad: a relinked-upon-execution executable
is some program .libs/lt-foo inside the build tree that gets
created when foo is executed; foo is a shell script that does this.
Does this make things clearer now?
Sorry for the confusion.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17311