This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Don't link ecj1 against libgcj.so.* (PR libgcj/38396)


Hello,

* Paolo Bonzini wrote on Thu, Dec 18, 2008 at 11:57:02AM CET:
> 
> > No.  It's in conflict with the patch that I already wrote and posted
> > to the list, and I'm about to commit.
> 
> In your patch you need to change -Wl,-L$(here)/.libs,-lgcj to
> -Wl,-L$(here)/.libs,-L$(here)/_libs,-lgcj to support OSes where the
> libtool internal directory is _libs (BTW maybe
> -Wl,-L.libs,-L_libs,-Wl,-lgcj works too?).
> 
> (/me notes to self to try understanding what is Libtool doing under your
> feet).

For what it's worth, some general remarks.

normally, it should never be necessary to specify .libs explicitly,
except to hide things from libtool.  Normal operation is that you
specify
  path/to/libgcj.la

which libtool will translate to something like
  -Lpath/to/.libs -lgcj
or
  -Lpath/to/.libs path/to/.libs/libgcj.so

at link time (plus either a run path at link time, or a wrapper
for the executable that sets LD_LIBRARY_PATH or similar); at install
time, this will be munged to
  -L$(libdir) -lgcj

plus a run path to $(libdir) if that isn't searched by default.

Using something like
  -Wl,-L$(here)/.libs,-lgcj

or
  -Wl,-L$(here)/.libs,-L$(here)/_libs,-lgcj

is probably designed to hack around libtool to trick it into not adding 
run paths for either uninstalled or installed dependencies.

What I don't understand is that, what having plain
  -L$(here)/.libs

(which Jakub's patch does) is desirable for.  It will lead to libtool
adding this path as -L for the installed .la file later, and may even
cause a run path to the build tree in installed libraries, which seems
undesirable.

Sorry I can't provide better help, I haven't looked closely at the
actual problems and patches.  I've always kind of wondered why Peter
Breitenlohner's patches to remove run paths pointing to the build tree
have never been applied (attached to the PR about this), but I won't
suggest them (more so at this point) without more scrutiny.

Cheers,
Ralf


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]