Re: Splitting dependency_libs in *.la?

[Ralf Wildenhues]

* Rex Dieter wrote on Mon, Oct 23, 2006 at 01:44:42PM CEST:
> Ralf Wildenhues wrote:
> > * Rex Dieter wrote on Tue, Oct 03, 2006 at 07:04:35PM CEST:
> >> Albert Chin wrote:
> >> 
> >> > And how do you handle the inherited_linker_flags variable in .la files?
> >> 
> >> Dunno, but hopefully implementation details can be overcome (by guru's
> >> with ample libtool-fu).
> > 
> > There is a difference between an implementation detail and a sound set
> > of semantics.
> 
> What else needs to be done except for implementation?

For example: answer the question that Albert asked.  It is not (purely)
a question of implementation.  But it is by far one of the easiest
questions to answer.

> Is there not agreement that this is a good approach to address the
> issues raised?  If not, I hadn't read any responses in this thread
> saying so.

I have yet to see a sound writeup of semantics how indirect library
dependencies are to work, in the light of the systems that Libtool aims
to support, including graceful degradation to systems which do not or
do not fully support indirect library dependencies.  There was ample
discussion on the Libtool lists, but no laid-out set of semantics.

If you only want to solve the problem for GNU/Linux systems (more
precisely: for systems with GNU binutils ld and a glibc ld.so), then
the issue becomes much simpler.  Once you start taking into account the
more than dozen different sets of possibilities that come into play on
other systems (just look at the output of `libtool --config | grep
hardcode' on a bunch of *nix hosts), the issue gets a bit more
complicated.

Add to that the prospect of cross-compilation, and the desire to execute
uninstalled programs (that depend on uninstalled libraries) in a
simulator environment, plus the issue of allowing a fast-install mode if
the user chooses not to test uninstalled stuff, and you'll reach a point
where things get complicated even on GNU/Linux.  Not just the
implementation, also merely laying out a sound set of semantics does.

Writing down expected behavior in the form of feature tests is a good
way to specify such semantics (albeit usually not a comprehensive one).

Cheers,
Ralf