libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LT_* equivalent to AC_CHECK_LIB?


From: Ralf Wildenhues
Subject: Re: LT_* equivalent to AC_CHECK_LIB?
Date: Mon, 3 Jul 2006 23:34:02 +0200
User-agent: Mutt/1.5.11+cvs20060403

* Tim Mooney wrote on Mon, Jul 03, 2006 at 11:17:03PM CEST:
> So to address this, libtool would need to
> 
> - know how the platform behaves regarding shared library dependencies
> - in the case of static libraries, continue doing what it's already doing
> - for shared libraries on platforms where the linker follows library
>   dependencies
>       - when creating a shared library, make sure that it's dependent
>         libraries are recorded (however that's done for a particular
>         platform, probably just linking) by the library when it's created.
>       - when linking against a shared library of this type, detect which
>         libraries are recorded as dependant for the shared library and
>         leave those out of the list of dependency_libs for the shared
>         library.
> 
> Is that about it?

No.  It's much more complicated.

If you allow the concept of indirect dependencies,

- you must make sure that uninstalled libraries which happen to be
  indirect dependencies, are properly linked against (instead of an
  earlier installed version) when executing uninstalled programs,

- that upon installation, libraries and programs properly do not contain
  any build-tree paths any more,

- match that with an aim to get -fast-install and -no-fast-install
  working properly, and with relink-upon-execution and relink-upon-
  installation,

- the many different semantics for hardcoding make this even "more
  interesting" ... for example, one we would need the information
  whether the linker and/or the runtime loader respect runpaths (and
  in which priority) for indirect dependencies, and whether with
  priority over the shlibpath variable.  This is trickier than you
  think: some GNU/Linux distributions even install GNU binutils with a
  different default...

Cheers,
Ralf
  




reply via email to

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