[Top][All Lists]

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

Re: use of libtool for linking executables - rpath problem

From: Paul Davis
Subject: Re: use of libtool for linking executables - rpath problem
Date: Mon, 19 Nov 2001 23:01:55 -0500

>> pkg-config doesn't do that. its an almost impossible task unless you
>Are you talking about some new tool that I had not previously heard
>about or are you talking about a script like the
>'/usr/local/bin/gnome-config' I see on my system?  

its a replacement for *all* such scripts. its a C program that works
with a great deal more intelligence than those scripts. its
independent of GNOME and everything else, for that matter.

>Unfortunately gtk standardized this type of script through
>proliferation. The proliferation occured because no other option was
>offered. It's mere popularity does not make it the right solution.

absolutely. thats why i am so enthusiastic about pkg-config. unlike
those silly scripts, pkg-config centralizes the information and at
least in theory it offers a point at which the kind of rationalization
and ordering problems discussed here can be solved.

>The scripts options do not even align with Autoconf since Autoconf
>distinguishes options with finer granularity than the *-config scripts
>  *-config     Autoconf
>  ==========   =================
>  --libs       LDFLAGS + LIBS
>  --cflags     CPPFLAGS + CFLAGS
>The munging of LDFLAGS and LIBS to create the output from the --libs
>option creates a bloody mess when you try to blend these options
>together.  Linker directory search order and library link order are
>totally lost if a simple concatenation of options is used.

Understood. As I mentioned before, this is an impossible task to
automate in the general case.

>The only proper solution is one based on a rules database in which the
>dependency requirements for each package can be expressed so that the
>dependencies can be reliabily satisified by the build environment.

No, thats insufficient. Link order is not solely a function of
dependency requirements. Its a complex interaction of user intent,
system configuration and library contents. Since the user intent is
the wild card, only some method by which the user can clearly express
her intent will work. If I want to link libhoard in at an early stage,
and libdmalloc later on, because i want free/malloc/realloc from hoard
to be used by the earlier objects, but the ones from dmalloc to be
used by the later ones ... there is no way that a dependency database
can infer this.

>Libtools .la files do not provide this database. Pkg-config scripts do
>not provide this database.

They do not, but they are closer to it, and form a much better
starting point than the godawful mess that libtool has turned into.
"libtool --gdb" for crying out loud!


reply via email to

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