public inbox for java-prs@sourceware.org
help / color / mirror / Atom feed
From: "Ralf dot Wildenhues at gmx dot de" <gcc-bugzilla@gcc.gnu.org>
To: java-prs@gcc.gnu.org
Subject: [Bug libgcj/17311] Wrong libgcc_s.so.1 is used by lt-gij
Date: Tue, 07 Feb 2006 17:18:00 -0000	[thread overview]
Message-ID: <20060207171835.10493.qmail@sourceware.org> (raw)
In-Reply-To: <bug-17311-682@http.gcc.gnu.org/bugzilla/>



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


  parent reply	other threads:[~2006-02-07 17:18 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-17311-682@http.gcc.gnu.org/bugzilla/>
2006-02-06 18:24 ` Ralf dot Wildenhues at gmx dot de
2006-02-06 19:03 ` hjl at lucon dot org
2006-02-07  5:48 ` Ralf dot Wildenhues at gmx dot de
2006-02-07 16:16 ` hjl at lucon dot org
2006-02-07 16:28 ` Ralf dot Wildenhues at gmx dot de
2006-02-07 16:48 ` hjl at lucon dot org
2006-02-07 17:18 ` Ralf dot Wildenhues at gmx dot de [this message]
2006-02-07 17:25 ` hjl at lucon dot org
2006-02-07 17:43 ` Ralf dot Wildenhues at gmx dot de
2006-02-07 18:45 ` hjl at lucon dot org
2006-03-01 17:39 ` hjl at gcc dot gnu dot org
2006-03-01 17:42 ` hjl at lucon dot org
2006-03-02  7:09 ` Ralf dot Wildenhues at gmx dot de
2004-09-03 20:27 [Bug libgcj/17311] New: " hjl at lucon dot org
2004-09-03 20:46 ` [Bug libgcj/17311] " mckinlay at redhat dot com
2004-09-03 20:52 ` hjl at lucon dot org
2004-09-09  3:42 ` pinskia at gcc dot gnu dot org
2004-09-09 16:25 ` hjl at lucon dot org
2004-09-14 18:42 ` hjl at lucon dot org
2004-09-16  0:11 ` hjl at lucon dot org
2004-10-11 20:13 ` tromey at gcc dot gnu dot org
2004-10-11 20:32 ` hjl at lucon dot org
2004-10-11 20:49 ` tromey at gcc dot gnu dot org
2004-10-11 21:01 ` hjl at lucon dot org
2004-10-11 21:27 ` tromey at gcc dot gnu dot org
2004-10-12 19:52 ` hjl at lucon dot org
2005-08-17  3:12 ` pinskia at gcc dot gnu dot org
2005-08-17 18:06 ` hjl at lucon dot org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060207171835.10493.qmail@sourceware.org \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=java-prs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).