[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gmp-4.0.1: Inter-library dependencies vs. DESTDIR installation
From: |
Kevin Ryde |
Subject: |
Re: gmp-4.0.1: Inter-library dependencies vs. DESTDIR installation |
Date: |
Thu, 09 May 2002 10:40:45 +1000 |
User-agent: |
Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.1 (i386-debian-linux-gnu) |
Christian Cornelssen <address@hidden> writes:
>
> Libtool relinks because it wants to safely avoid cases where paths to
> build directories are coded into installed binaries. Therefore, the
> problem is not just that -lgmp cannot be found; if found, it must also
> reside in a non-temporary directory, at least in systems where library
> paths are hardcoded into the binaries.
Yes, thanks, I'll try to clarify that (new text below).
> If using the -L option results
> in an "ldd" on the pseudo-installed libgmpxx.so showing libgmp.so.3 in
> an unwanted directory, that trick is not recommendable. If that is
> why you require a SVR4 style system, forget my blurb... :-)
Yes, SVR4 uses only a soname I believe.
> Anyway, when using -L does _not_ lead to hardcoded library paths, the
> system is likely to support omitting -lgmp completely. This would
> correspond to removing the `libgmp.la' from libgmpxx_la_LIBADD.
I'd like to keep the dependency if possible, since it expresses the
true relationship, even if that information can only really be used by
libtool.
> However, whether both solutions apply to the same set of operating
> systems is just my estimate. Call it a guess if you like, or (better)
> tell me about counterexamples :-)
Windows DLLs maybe, not sure. Mind you as far as gmp goes I'm not
sure if C++ DLLs work at all (on cygwin that would be).
`DESTDIR' and shared `libgmpxx'
`make install DESTDIR=/my/staging/area' or the same with a `prefix'
override to install to a temporary directory is not fully
supported by current versions of libtool when building a shared
version of a library which depends on another being built at the
same time, like `libgmpxx' and `libgmp'.
The problem is that `libgmpxx' is relinked at the install stage to
ensure that if the system puts a hard-coded path to `libgmp' within
`libgmpxx' then that path will be correct. Naturally the linker is
directed to look only at the final location, not the staging area,
so if `libgmp' is not already in that final location then the link
will fail.
On systems which don't hard-code library paths, for instance SVR4
style systems such as GNU/Linux, a workaround is to insert a
suitable `-L' in the `relink_command' of `libgmpxx.la' after
building but before installing. This can be automated with
something like
sed '/^relink_command/s:libgmp.la:-L /my/staging/area libgmp.la:' \
<libgmpxx.la >libgmpxx.new
mv libgmpxx.new libgmpxx.la