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

[Ken Moffat]

On Thu, Jan 17, 2008 at 08:58:33PM -0500, Joe Ciccone wrote:
> Ken Moffat wrote:
> >  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.
> >   
> This is already done for the most part, And if I've missed something, it
> needs to be changed.

 Actually, it turns out that many of my problems were from xmkmf,
particularly the several configure scripts that decided, for -m32,
that X was in /usr/lib64.

 It goes all the way back to my "how on earth do I get this mess of
programs to build for 32 and 64 in a way that I can test them ?"
thoughts about modular X.  To start with, I built a core X as
32-bit, including enough to run twm, xterm, and a few apps as
32-bit.  So everything was built 32-bit, then I rebuilt most of it
as 64-bit, but not the utilities.  Gradually, I dropped a lot of the
32-bit stuff.  Late last year I decided I might as well use the
64-bit compiler for the utilities.  By the time I got to building
gnome packages, I'd forgotten about that.  As always in a gnome
version upgrade on multilib, I had to add LDFLAGS='-L/lib
-L/usr/lib' to 32-bit packages which had gone straight through
before.  I also added a lot of extra 32-bit things, and some of
those needed --with-x-libraries= to stop them trying to link to
/usr/lib64.

 Yesterday, I was trying to build without -L or --with-x-libs except
where needed.  The first breakage (dbus), I couldn't grok what was
happening.  The next one (libbonoboui) seemed a bit confusing, but I
eventually realised it was running xmkmf.  Consult cblfs, try what
that said for xorg-cf and imake, didn't really help.  Looked at the
templates, eventually came up with a brute-force sed which fixed it
for me (and for dbus).

 So, although I haven't built a full desktop like this yet (some of
the early things, like jpeg, had these workarounds), I'm now
starting to think that adding LDFLAGS=-L, or --with-x-libs, is a
sign that all is not well with the infrastructure which supports the
configure scripts.  Yes, there are good reasons to *sometimes* specify
things, e.g. I only build Python as 32-bit, so libxml2 and libxslt
find the headers and try to link to it when I'm building them as
64-bit unless I disable it.

 I'm suspicious about the configure scripts for a few packages which
failed to find 64-bit libraries before I'd fixed what I've now found,
and gnash is a law unto itself for where it looks (for 32-bit on
multilib,
 echo '${with_top_level}/lib /usr/lib /lib .. ../..' >macros/libslist
works for me).

 Looking at my logs from an almost complete desktop (still some of
kde to do), the following -config programs are definitely used (most
common first):

 pkg-config,
 freetype-config,
 xml2-config,
 cups-config (espgs, gutenprint, libgnomecups, kdebase),
 scrollkeeper-config (gnome),
 artsc-config (kde, SDL),
 esd-config (libao, SDL),
 libart2-config (several kde packages),
 sdl-config (gst-plugins-bad, agg),
 firefox-config (librsvg),
 gpg-error-config (libgcrypt).
 libgcrypt-config (gnome-keyring)
 pcre-config (kdelibs),
 xft-config (icewm),
 xslt-config (scrollkeeper).

This might not be the full list, gedit uses scrollkeeper-config but
doesn't test to see if it works (only found that out because I build
32-bit rarian, which symlinks scrollkeeper-config to rarian-config,
and I ended up with scrollkeeper-config -> multiarch_wrapper with
scrollkeeper-config-32 -> rarian-config and rarian-config ->
multiarch_wrapper : not nice, it didn't get as far as
rarian-config-32 - looping), there might be others that I
overlooked because they don't show up in the config output.

 Maybe I'll follow up on this when I can be bothered to build x86_64
multilib.

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