bug-gmp
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]