Unpleasant problem w/ foo-config style scripts (and possible solutions).

[Rob Browning <rlb at defaultvalue dot org>]

I was wondering there's been any thought given to fixing the following
problem which makes the foo-config style scripts unusable in some
common situations.

Problem Description:
--------------------
Imagine that an admin has versions of two packages, say guile and glib
installed in /usr/local, and then imagine that a user installs their
own version of glib into /home/bar/opt/glib-debug that they wish to
use.  Now also imagine the reverse, where the guile they want to use
is installed in /home/bar/opt/guile-debug instead.

Given the current arrangement and handling of the foo-config
scripts, there is no obvious way that developers can write Makefiles
(or autoconf/automakery) for a package that depends on glib and guile
that will allow a user to build the package against both the
/usr/local guile and the /home glib, or the /usr/local/ glib and the
/home guile.

This is because whichever package is installed in /usr/local will put
a -L/usr/local/lib into it's foo-config script's link output,
and if that package happens to be the first one listed in the CFLAGS
in the Makefile (or in configure.in), then it will shadow the
-L/home/bar/opt/... specification in the other package's foo-config
script.

This is also a problem right now with /usr/lib since at least both
guile and glib's foo-config scripts specify -L/usr/lib, even when they
don't need to.

Possible Solutions:
-------------------
After thinking about it for a bit, I can propose a few possible
solutions, though these may not be the best ones:

  1) The cleanest solution might be for gcc (and ld) to add
     --save-lib-path and --restore-lib-path options that would push and
     pop copies of the -L library path respectively.  Then every
     foo-config script could cleanly wrap their link output in a
     save/restore pair, and the problem would vanish.  For the
     guile glib case you would have:

       --save-lib-path -L/usr/local/lib --restore-lib-path \
         --save-lib-path -L/home/bar/opt/glib-debug/lib --restore-lib-path

     which would work fine.  The save/restores could also handle
     nesting as well (as you would have if gtk-config generated and
     included glib-config's output at runtime).

  2) Make sure that when building on a given platform, guile, glib,
     and any other program generating a foo-config script check with
     gcc (or whichever cc, if possible) and see which libs (like /lib
     and /usr/lib) are defaults.  These should then be omitted from
     the foo-config's link output.  Though this doesn't really solve
     the problem.  It just eliminates it in the most common case.  In
     particular, it doesn't help in the /usr/local case, or any other
     case where multiple packages are being installed with mingled
     files rather than an /opt style package-per-dir install.

  3) See if incremental linking is possible (I have no idea myself),
     and get people to start using incrementally linking.  i.e. link
     app against wichever version of guile you want, then glib, then
     ..., though this seems the least feasible.

Option (1) sounds the cleanest to me, but would only work with gcc
(though that may be true of (2) and possibly (3) as well).

Thanks

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD