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

[Samir Mishra]

Thanks for a most thorough explanation. Your response should be included 
in the AMD64 handbook.

> However, 32-bit is possible by adding the appropriate CFLAGS.

I assume this can be achieved by switching the CHOST environment variable to the X86 relevant one. In this instance, if I change the CHOST variable, is it also necessary to add -m32 to the CFLAGS, or for that matter, make any changes to the C[XX]FLAGS?

Also, given that I have the multilib libraries installed, is there any 
way to ensure that only the 64-bit libraries are used when compiling, in 
effect disable all 32-bit libraries during the compile stage? I'm more 
interested in having things work, but I would like to keep track of all 
packages that use any of the 32-bit libraries and upgrade these to the 
full 64-bit versions when updates to the packages are available.

Thanks again.

Duncan wrote:
> 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.
>
>

-- 
gentoo-amd64@g.o mailing list