Ken Moffat ken at
Mon Jan 2 06:48:54 PST 2006

On Sun, 1 Jan 2006, Dennis J Perkins wrote:

> I've noticed this with a few Gnome packages, where it complains that a
> file is missing from /usr/lib, when it is actually in /usr/lib64.
> Usually, it's a .la file that a pckage complains about.  Gnome-desktop
> does the same, but it also wants and to
> be in /usr/lib.
  To build a multilib desktop, you need to design it first!  For example, 
on x86_64 the only likely reasons to build 32-bit are to use plugins 
(e.g. for firefox), or to use software that is too broken to build as 
64-bit (reputedly, OOo) - in general, x86_64 progs are marginally bigger 
than x86, but gain a lot of speed from having more registers for the 
compiler to use.  On RISC machines the justifications can be different 
(32-bit apps will use less memory when running).

  So, first you have to decide which applications need to be 32-bit, then 
check all their dependencies: any libraries these supply have to be 
32-bit, any binary progs like e.g. unzip can be either.  If a library is 
needed in both sizes, you have to build it twice AND save any useful 
programs (e.g. freetype-config) so that you can point the configure 
process to the correct program.

  Sometimes, Makefiles have lib hardcoded into various paths - in 
general, try to configure, then grep for 'lib/' in the configured files, 
and look at where it came from.  There is no one-size-fits-all approach 
to configuring packages to use lib64.

  At the moment, my multilib desktop only has minimal gnome, and no kde, 
so I can't provide detailed advice beyond noting that almost all my 
multilib problems were with the 32-bit versions.

  With .la files, you need to inspect them to make sure that even though 
they are in lib64/ the dependency_libs do not reference /usr/lib or 

  das eine Mal als Tragödie, das andere Mal als Farce

More information about the cross-lfs mailing list