This is the mail archive of the
java-prs@gcc.gnu.org
mailing list for the Java 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: java-prs at gcc dot gnu dot org
- Date: 7 Feb 2006 17:18:35 -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 #21 from Ralf dot Wildenhues at gmx dot de 2006-02-07 17:18 -------
(In reply to comment #20)
> What did you mean by *installed programs*
In my notation, installed programs live below $prefix.
They must not contain any reference to the build tree.
You showed an installed program in comment #18, which
has an erroneous run path.
> The executable in question is
>
> [hjl@gnu-13 .libs]$ readelf -d
> /export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/libjava/.libs/gij
> | grep RPATH
> 0x000000000000000f (RPATH) Library rpath:
> [/usr/gcc-4.2/lib/../lib64]
This is an uninstalled program: it lives below $builddir.
It should of course have a run path entry to the newly-built
library (which also lives below $builddir).
One of my points was that, if that uninstalled program also
has a run path entry pointing to /usr/gcc-4.2/lib/../lib64,
but that comes after all the run paths which point to inside $builddir,
then that is not a big problem.
> Is is your *installed programs*?
No.
> My point is when you run a newly built executable
> in the build tree, it should use the newly built shared libraries in the build
> tree. It is a long standing bug in gcc/libtool.
Yes, correct. It's one of my medium term quests to fix this.
The converse issue (from a libtool POV) is just GCC bug 5291.
Again from a libtool POV it is convenient and useful to attack both
issues at the same time.
One of the open questions that I could not answer myself yet:
When you issue `make install' for GCC, is there a guarantee by the GCC
build machinery that
- libraries are installed in the correct order
(libgcc_s.so before libgcj)? I strongly assume yes.
- For each libtool-created library, in case it needs to be relinked
at install time, does the relink command have appropriate -L (and maybe -R)
flags pointing to the installed non-libtool libraries
(e.g., $prefix/lib/libgcc_s)?
In comment #18, you show that for this build, the second question is true.
I need to know however if it is true in any case, for any value of $host.
Iff both questions can be affirmed, then the next question can also
be made true:
- If libtool erased both all `-L' and all `-R' flags pointing inside the
build tree from the relink command that may be issued at `make install'
time, would installation still succeed?
Then we have a chance to fix this portably in libtool, not only for
GNU/Linux.
Another small but important question:
- Do there exist directories in the GCC build tree where both libtool-created
and non-libtool-created libraries are (possibly) built?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17311