[BCLFS] multilib pango (32-bit)
ryan.oliver at pha.com.au
Tue Nov 22 19:03:48 PST 2005
On Tue, 2005-11-22 at 19:19 +0000, Ken Moffat wrote:
> a files from glib-2, and evaluates these to
> /usr/lib64/libgobject-2.0.so (and perhaps others) during the link.
> I'm configuring with -x-libraries=/usr/X11R6/lib (stops lib64
> in the Makefile) and building with (watch for line wrap)
> FREETYPE_LIBS='/usr/lib/libfontconfig.so /usr/lib/libexpat.so
> /usr/lib/libfreetype.so' which stops the 64-bit versions being pulled
> from the opentype subdirectory.
> As far as I can see, overriding GLIB_LIBS won't help, it becomes
> '-lgobject-2.0 ...' in configure so it doesn't specify where the
> libraries are to be linked from. I can't seem to find a way of
> specifying which libgobject-2.0.la should be used, and it seems to
> default to the 64-bit version in /usr/lib64.
> Tried --build and --host like glib-2, but it doesn't solve this
> problem. Tried updating ltmain.sh from /usr/share/libtool, but no
> better. There isn't an ltconfig.
> I'm out of ideas. Has anybody built pango (32-bit) on a recent
> multilib ? If so, which version, and what needed to be done
> differently ?
Built pango 1.8.1 multilib a while back
First issue is gonna be all the foo-config files under /usr/bin.
Unless you kept both 32bit and 64bit versions of these files around
(such as freetype-config, glib-config ) you have all manner of fun as
these files are generally run by configure to determine cflags, ldflags
I generally keep both versions of all *-config files and use a wrapper
to select the correct one.
As for libtool silliness in pulling in the wrong .la file, I generally
only see that happening when building 64bit when I have 32bit libs
Easiest way to avoid that issue is to pass LDFLAGS="-L/lib
-L/usr/lib" ( or -L/lib64 -L/usr/lib64 for 64bit) during configure so
libtool processes those directories for .la files first.
Note however I did not find the above LDFLAGS necessary for pango...
More information about the cross-lfs