[gentoo-amd64] Re: Difference between multilib & no-multilib stages

[Duncan]

Samir Mishra posted <44489DFB.4070705@×××.ae>, excerpted below,  on Fri,
21 Apr 2006 12:55:23 +0400:

> What's the difference between the multilib & no-multilib stages? If I'm
> compiling all packages with the X86_64 CHOST flag, will packages always
> compile with X86_64 libs even when 32-bit libraries are on the system if
> I use multilib?

Multilib stages will have a 32-bit capable (both 64-bit and 32-bit) gcc,
and will have glibc libraries for both bitnesses as well.  I'm not sure if
the portage sandbox is included in the stages or only added later (stages
include bare-minimum cut-down versions of some things, cutting out
dependencies they'd otherwise have), but if it's included, there'd be
both 64-bit and 32-bit versions of it, as well.  No-multilib will only
include the 64-bit capabilities -- no 32-bit included.  (To switch from
multilib to no-multilib later on is therefore relatively easy, just switch
your profile, merge grub-static replacing grub, and remerge gcc, sandbox,
and glibc.  The reverse, no-multilib to multilib, is far harder, the
easiest way being to install from the multilib stages and go from there.)

With the X86_64 CHOST and multilib, it'll default to 64-bit compiling,
yes.  However, 32-bit is possible by adding the appropriate CFLAG.

Note that under normal circumstances, you'll not want to emerge anything
in 32-bit mode (save for stuff like grub and glibc that are special cases
it knows about -- grub is 32-bit only, glibc is compiled both ways
automatically, if you have a multilib toolchain and profile), as portage
can't track 32-bit and 64-bit dependencies separately, so forcing 32-bit
compilation of some things, using the default 64-bit for others, is a FAST
WAY TO A BROKEN SYSTEM!!

Two ways around that:  Either (1) use a dedicated 32-bit chroot, with its
own 32-bit portage instance that doesn't know anything about the main
system and just tracks 32-bit stuff, or (2) do all your 32-bit compiling
from tarball, not using portage.  The chroot option will be preferable if
you do a lot of 32-bit compiling, as it will allow the 32-bit portage
instance to do what package managers are supposed to do -- track
dependencies for you.  There's documentation available to help.  If you
are only doing a single 32-bit app or two, and the needed libraries are
pretty basic/mainline, you can probably emerge the needed 32-bit
compatibility libraries (binaries), and only merge the specific individual
32-bit app you need.  This will be easier if you aren't doing enough
32-bit compiling to make the automated portage handling of 32-bit
dependency tracking worth the trouble of maintaining an almost=complete
32-bit Gentoo installation in the chroot.

FWIW, 64-bit binaries can't use 32-bit libraries, neither can 32-bit
binaries  use 64-bit libraries, and gcc is smart enough not to try -- if
it can't find the right ones, it causes the compile to fail.  

One example of this is compilation against the OpenGL libraries. 
Unfortunately, opengl-update (or eselect opengl if you are running the
newer eselect, which I believe is ~arch only at this point) doesn't always
get the symlinks to the headers pointed to the correct ones, sometimes
trying to use the 32-bit ones if the appropriate 32-bit compatibility
libraries are merged, instead of the 64-bit ones.  It's not uncommon for
folks to have problems  merging anything that depends on these, until they
correct the symlinks manually, to point them at the 64-bit versions. 
However, if gcc can't find the right ones, it will simply error out,
allowing you to fix the problem, as it can't compile properly against the
wrong ones.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@g.o mailing list