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

[Samir Mishra]

I guess my assuming that I can change the bit-ness of the compilation
via the CHOST variable is a misunderstanding on my part.

If my primary Gentoo install is using the multilib libraries, can I just
  move application packages from a 32-bit chroot to the former and
expect things to work? I've set up glibc with nptl-only. I was planning
to set up a pure 32-bit and pure 64-bit chroot environments. The latter
would have served as a development setup, allowing me to complete all
compiles and move the working applications from the 64-bit chroot to the
main Gentoo instance.

BTW, I actually went through all the documentation you mention and it
was very helpful. I'm just setting up an installation that's a bit more
than trivial, using GCC 4 & X-server. I expect to be referring to the
experience of the good folk on this list often!

Thanks again.

Samir.

Duncan wrote:
> Samir Mishra posted <4448CA27.8020804@×××.ae>, excerpted below,  on Fri,
> 21 Apr 2006 16:03:51 +0400:
>
>
>>> 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?
>>
>
> I'm not sure about the effect of CHOST.  The docs mention -m32 (and -m64)
> in CFLAGS, and that's the way they manage it with the glibc and grub
> ebuilds.
>
> Other changes to the CFLAGS would depend...  Some CFLAGS work on both but
> the effect is somewhat different (-fomit-frame-pointer kills certain
> debugging on x86, but not on amd64/x86_64). Some don't work on on both
> (certain alignment flags), or don't work on all x86 sub-archs (SSE/MMX and
> the like). However, if you stick to the recommended -O2 -pipe (and
> possibly -fomit-frame-pointer if you don't care about the debugging on
> x86), -m32/64 is the only one to worry about, and again, I'm not sure how
> that works against CHOST.  (-O flags will change their behavior based on
> arch, but in /general/, the idea is to only select the generally safe
> optimizations for a platform and include those in the various levels of
> -O, as appropriate.)
>
>
>> 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.
>>
>
> As I said, you don't really need to do that, because if it's a 32-bit
> package, it can only use 32-bit libraries; if it's a 64-bit package, it
> can only use 64-bit libraries.  The only exceptions in portage are well
> known -- gcc, glibc, sandbox, grub, and the 32-bit bin/compatibility
> packages that don't compile anything but simply install precompiled 32-bit
> binaries for compatibility purposes.  gcc does both in ordered to be
> multilib.  glibc actually compiles separate libraries for 32-bit and
> 64-bit -- it iterates thru the build process up to four times, once each
> for nptl and linux threads (if so configured), for each of 32-bit and
> 64-bit (on a multilib profile).  sandbox likewise duplicates the build
> process, building both a 32-bit lib and a 64-bit lib, so it can provide
> the sandbox services to both bitnesses.  grub is 32-bit only, because the
> hardware /must/ start in 32-bit mode and only switches to 64-bit mode
> after the kernel loads.
>
> Anything that you compile outside of portage, presumably, you know and
> deliberately tell it which bitness to compile for.
>
> Thus, the only cases where an unintended bitness libraries are used are
> accidents, and in those cases, gcc will bail anyway, not completing the
> build, because it simply /cannot/ link 32-bit and 64-bit together.
>
> (The exception is where special thunking layers are designed in.  The
> partially binary-only slaveryware that's NVidia's videodrivers are an
> example of this.  However, again, this is going to be very rare as it's a
> huge pain to do, so anything that does it you'll know about, because it
> will be a feature of the product.)
>
> Here are some interesting links you may have missed.
>
> The handbook, which you already mentioned, but for completeness.  Note
> that many folks  only read the installation section, and miss the many
> good hints about actually working with and sysadmin-ing their Gentoo
> system.  The Working with Gentoo and Working with Portage sections should
> also be at least scanned, and the network section can be very helpful for
> those setting it up for the first time as well:
>
> http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml
>
> Gentoo AMD64 FAQ, which deals with some of this:
>
> http://www.gentoo.org/doc/en/gentoo-amd64-faq.xml
>
> The now deprecated Technotes.  Most of the stuff here is covered in the
> FAQ, but here's a somewhat dated historical viewpoint.  Still well worth
> the read, as they deal with some of these questions as well.
>
> http://www.gentoo.org/proj/en/base/amd64/technotes/index.xml
>
> The 32-bit chroot guide.  If you decide you'll be doing a lot of 32-bit
> stuff, this is the way to go.
>
> http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=2
>
>




-- 
gentoo-amd64@g.o mailing list