[Clfs-support] cblfs: A suggestion for /usr/bin/*-config in multilib

[Ken Moffat]

 For a long time, I've wondered why I sometimes have to add
LDFLAGS="L/lib -L/usr/lib" to some packages to get them to link when
building as 32-bit on my multilib builds (I don't have mips, so
multilib is straight 32/64 for me).  Whenever I've looked at cblfs,
I've not seen people needing to do this.

 Some of the packages and libraries I use are only built as -32
(e.g. Python, various av libs, aspell), other packages (and maybe
libraries) are only built as 64-bit - I don't have the space to add
things which _might_ be useful, every package has to justify its
use, and on multilib they also have to justify being built as -m32
or -m64 !

 I sorted out the unholy glib/gtk/atk/pango mess a couple of years
ago, and I think some of what I do differs from common practice
(particularly, my script for gdk-pixbuf-query-loaders which runs both
the -32 and -64 versions : it's a runtime thing, so USE_ARCH isn't
relevant - without this, I had a 32-bit audacious running one day,
then the graphic buttons on it were trashed the next day after I'd
built the 64-bit tools).  But, I symlink some programs from pango and
gtk2 to multiarch_wrapper in the normal way.

 Most of my current desktop came later, at least on multilib, and
I've just thrown packages into the mix and worked around problems.
In december I noticed there are an awful lot of -config programs in
/usr/bin, some of which provide library information including the
directory.  I had intended to try linking _all_ of these -config
programs to multiarch_wrapper, but I forgot, so a full test will
need to wait for my next build.

 BUT, I *think*  I'm finding that in at least some cases, if I have
a symlink pointing to multiarch_wrapper (because the 32-bit build of
foo caused me to link to multiarch_wrapper), I end up with programs
in foo and foo-64 from the second build, instead of a symlink in foo.
Has anybody else seen this, or have I misinterpreted my earlier
errors ?

 I'm now deleting foo _if_it_is_a_symlink_ [ -h ] before I run 'make
install' for any package where I'm going to symlink foo to
multiarch_wrapper.  I guess the same will be necessary if rebuilding
(or upgrading) the 32-bit version, but maybe I'm just wasting time
deleting the symlink before 'make install' ?

 I'm starting to think that on multilib, any -config program should
be symlinked to multiarch_wrapper as a matter of course.  A few of
them probably don't make any difference (their --libs option doesn't
specify /lib or /lib64), and for others it isn't the whole story,
e.g. libxml2 and libxslt try to build their .py parts even if
python2.5-config leads nowhere because the -64 variant doesn't exist
(add --without-python).

 So, at last the suggestions:

1. Would it be useful to add a general page about /usr/bin/*-config
to cblfs for multilib ?  It could suggest that whenever a -config
program is installed, it will at worst do no harm to move it to -32
and/or -64 as appropriate, and symlink it to multiarch_wrapper. (If
you only build it in one size, the symlink will prevet any configure
script of the other size (or other API, or whatever the correct name
for -m32|m64 is) from finding it.

 If it is worth adding this, what should it be called ?  '*-config'
doesn't seem a particularly useful name.

 Many of the -config programs (and the fc- programs) are already
mentioned in appropriate packages in cblfs, but I've found some
others that maybe ought to be (haven't yet confirmed that they
all definitely mention /lib or /lib64 yet, e.g. xft-config --libs
from libXft doesn't).  Maybe -config programs which don't explicitly
mention /usr/lib or /usr/lib64 should be explicitly mentioned as not
needing to be symlinked ot multiarch_wrapper ?

 People will always add packages to their systems that aren't in
cblfs, and I for one wasn't really aware that -config programs might
be contributing to difficulties in building later packages.

2. If it is worth adding a general page about this, should it mention
that temporarily removing a symlink to multiarch_wrapper immediately
before (re-)running make install may be helpful ?

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce