--- Comment #27 from Ralf dot Wildenhues at gmx dot de 2006-03-02 07:09
---
(In reply to comment #25)
> PR libgcj/17311
> * ltmain.sh: Don't use "$finalize_rpath" for compile.
This change will cause breakage on systems when relinking is done at
installation time, and on
--- Comment #26 from hjl at lucon dot org 2006-03-01 17:42 ---
Fixed.
--
hjl at lucon dot org changed:
What|Removed |Added
Status|WAITING
--- Comment #25 from hjl at gcc dot gnu dot org 2006-03-01 17:39 ---
Subject: Bug 17311
Author: hjl
Date: Wed Mar 1 17:39:35 2006
New Revision: 111607
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111607
Log:
2006-03-01 H.J. Lu <[EMAIL PROTECTED]>
PR libgcj/17311
--- Comment #24 from hjl at lucon dot org 2006-02-07 18:45 ---
For uninstalled executables in the build tree, like lt-gij, libtool may put all
directories, which are in the build tree, passed by -L, into DT_RPATH. It may
add more DT_RPATH entries than necessary. If you want fancy one, yo
--- Comment #23 from Ralf dot Wildenhues at gmx dot de 2006-02-07 17:43
---
(In reply to comment #22)
> - Do there exist directories in the GCC build tree where both libtool-created
> and non-libtool-created libraries are (possibly) built?
>
> That is THE KEY question. The executable
--- Comment #22 from hjl at lucon dot org 2006-02-07 17:25 ---
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?
That is THE KEY question. The executable in questi
--- 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 progra
--- Comment #20 from hjl at lucon dot org 2006-02-07 16:48 ---
What did you mean by *installed programs*. The executable in question is
[EMAIL PROTECTED] .libs]$ readelf -d
/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/libjava/.libs/gij
| grep RPATH
0x00
--- Comment #19 from Ralf dot Wildenhues at gmx dot de 2006-02-07 16:28
---
(In reply to comment #18)
> Why do I want
>
> [EMAIL PROTECTED] gcc]$ readelf -d /usr/gcc-4.2/bin/gij | grep RPATH
> 0x000f (RPATH) Library rpath:
> /export/build/gnu/gcc/build-x86_64
--- Comment #18 from hjl at lucon dot org 2006-02-07 16:16 ---
There are
[EMAIL PROTECTED] gcc]$ readelf -d /usr/gcc-4.2/bin/gij | grep RPATH
0x000f (RPATH) Library rpath:
[/usr/gcc-4.2/lib/../lib64]
[EMAIL PROTECTED] gcc]$
Why do I want
[EMAIL PROTECTED] gcc
--- Comment #17 from Ralf dot Wildenhues at gmx dot de 2006-02-07 05:48
---
(In reply to comment #16)
> Please read the summary line: "Wrong libgcc_s.so.1 is used by lt-gij". Ld.so
> will search DT_RPATH first for any shared libraries.
Yes. So all that is missing is a notion in libtoo
--- Comment #16 from hjl at lucon dot org 2006-02-06 19:03 ---
Please read the summary line: "Wrong libgcc_s.so.1 is used by lt-gij". Ld.so
will
search DT_RPATH first for any shared libraries. If you have DT_RPATH entries
pointing to installed paths to libraries/executables in the build
--- Comment #15 from Ralf dot Wildenhues at gmx dot de 2006-02-06 18:24
---
(In reply to comment #8 by H. J. Lu)
> See
>
> http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02467.html
>
> I don't know how to do --disable-fast-install for gcc.
> --enable-fast-install is totally wrong for EL
--- Additional Comments From hjl at lucon dot org 2005-08-17 18:06 ---
FWIW, the bug is still there.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17311
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-17
03:12 ---
What is the status of this bug (why is this still in waiting)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17311
--- Additional Comments From hjl at lucon dot org 2004-10-12 19:52 ---
You are right. The second patch isn't needed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17311
--- Additional Comments From tromey at gcc dot gnu dot org 2004-10-11 21:27
---
I'm afraid I couldn't really parse that.
To me it looks like libjava_find_gij looks for
"gij" in the build directory. This in turn is
a shell script which, if needed, creates lt-gij.
The fact that the inst
--- Additional Comments From hjl at lucon dot org 2004-10-11 21:01 ---
.libs/lt-gij is used by "make check". Try
# grep -i gij */*.exp
in libjava/testsuite.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17311
--- Additional Comments From tromey at gcc dot gnu dot org 2004-10-11 20:49
---
I read that. What I observe is that .libs/gij is created
by the build. Then if I run gij (not .libs/gij), it creates
.libs/lt-gij.
My understanding is that --enable-fast-install is what makes
all this work
--- Additional Comments From hjl at lucon dot org 2004-10-11 20:32 ---
See
http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02467.html
I don't know how to do --disable-fast-install for gcc.
--enable-fast-install is totally wrong for ELF. It should
never be used for any ELF targets.
--
h
--- Additional Comments From tromey at gcc dot gnu dot org 2004-10-11 20:13
---
I read through these patches a little.
I don't understand why ltmain.sh is the way it is,
but Gary's comment seemed appropriate.
http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02333.html
Doesn't the second pa
21 matches
Mail list logo
