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 _______________________________________________ Clfs-support mailing list [email protected] http://lists.cross-lfs.org/listinfo.cgi/clfs-support-cross-lfs.org
