[gentoo-dev] {bi,multi}arch support for all x86/amd64/ppc/sparc systems

[gentoo-dev] {bi,multi}arch support for all x86/amd64/ppc/sparc systems

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 821 bytes --]

there's a bug open atm requesting we add biarch support to our x86/amd64 
compilers [1].  i'd like to take this further and do it for all ppc systems 
too (sparc has already done this).  basically, this just affects the code that 
gcc can generate.  it does not affect the libraries it includes.

i haven't heard any feedback from peeps, so if no one has any reason not to do 
this, i'll enable it prob this weekend.

the advantage is that it should obsolete the separate kgcc64 package for most 
people.  and i think it might help out with the multilib bootstrap issue: you 
can't build multilib gcc without a multilib glibc, and can't build a multilib 
glibc without a multilib gcc, but i think you should be able to build a 
multilib glibc with a multiarch gcc, and then a multilib gcc after that.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] {bi,multi}arch support for all x86/amd64/ppc/sparc systems

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 74 bytes --]

for those who cannot read minds:
[1] https://bugs.gentoo.org/349405
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[gentoo-dev] Re: {bi,multi}arch support for all x86/amd64/ppc/sparc systems

[Duncan]

Mike Frysinger posted on Wed, 07 Dec 2011 17:15:47 -0500 as excerpted:

> the advantage is that it should obsolete the separate kgcc64 package for
> most people.  and i think it might help out with the multilib bootstrap
> issue: you can't build multilib gcc without a multilib glibc, and can't
> build a multilib glibc without a multilib gcc, but i think you should be
> able to build a multilib glibc with a multiarch gcc, and then a multilib
> gcc after that.

1) Will this allow building grub from amd64/no-multilib, thus avoiding 
having to have grub-static?  That's the one thing I don't like about no-
multilib, having to use the pre-built grub-static.

2) What about grub-2, and while we're on it, is a switch to that expected 
any time soon, and/or is there a grub-static-2 in the wings?  With the 
grub-1 gpt patches (and hopefully btrfs support at some point) I'm not 
sure that staying with grub-1 isn't my preference in any case, but I do 
worry how long that's going to be viable, especially with btrfs coming 
and no grub-1 btrfs support that I'm aware of, and I have literally /no/ 
idea what might or might not be in gentoo's pipeline,
grub-wise.

3) One thing I very much like about no-multilib is the shorter gcc (and 
glibc) builds.  This will kill that (for gcc), right?  USE flag activated 
to avoid that for those who want to?  (Of course I realize that it's 
unlikely I can keep/get both the shorter gcc builds and support for grub 
builds.)

-- 
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

[gentoo-dev] Re: {bi,multi}arch support for all x86/amd64/ppc/sparc systems

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1074 bytes --]

On Thu, 8 Dec 2011 02:12:37 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> 2) What about grub-2, and while we're on it, is a switch to that expected 
> any time soon, and/or is there a grub-static-2 in the wings?  With the 
> grub-1 gpt patches (and hopefully btrfs support at some point) I'm not 
> sure that staying with grub-1 isn't my preference in any case, but I do 
> worry how long that's going to be viable, especially with btrfs coming 
> and no grub-1 btrfs support that I'm aware of, and I have literally /no/ 
> idea what might or might not be in gentoo's pipeline,
> grub-wise.

I think grub-0.97 was one of the first things I worked on as a user becoming
interested in development sixish years ago.  It was a god-awful mess then.
It's much worse now.

It's also keeping 4.6.2 out of ~arch. :/


-- 
fonts, gcc-porting,                  it makes no sense how it makes no sense
toolchain, wxwidgets                           but i'll take it free anytime
@ gentoo.org                EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: {bi,multi}arch support for all x86/amd64/ppc/sparc systems

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 639 bytes --]

On Wednesday 07 December 2011 21:12:37 Duncan wrote:
> 1) Will this allow building grub from amd64/no-multilib, thus avoiding
> having to have grub-static?  That's the one thing I don't like about no-
> multilib, having to use the pre-built grub-static.

grub needs a C library to link `grub`.  at that point, you have multilib.  
that's the only difference between the two profiles: one has a multilib 
glibc/gcc and one does not.

> 3) One thing I very much like about no-multilib is the shorter gcc (and
> glibc) builds.  This will kill that (for gcc), right?

no.  please re-read what i said: this is not multilib.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] {bi,multi}arch support for all x86/amd64/ppc/sparc systems

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 85 bytes --]

committed:
http://sources.gentoo.org/eclass/toolchain.eclass?r1=1.509&r2=1.510
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] {bi,multi}arch support for all x86/amd64/ppc/sparc systems

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1431 bytes --]

On Wednesday 07 December 2011 17:15:47 Mike Frysinger wrote:
> the advantage is that it should obsolete the separate kgcc64 package for
> most people.  and i think it might help out with the multilib bootstrap
> issue: you can't build multilib gcc without a multilib glibc, and can't
> build a multilib glibc without a multilib gcc, but i think you should be
> able to build a multilib glibc with a multiarch gcc, and then a multilib
> gcc after that.

a followup: have glibc always install headers for all possible ABIs.  this 
might sound like a lot, but in practice, it amounts to only a handful as glibc 
by default includes support for all ABIs in common headers.

the most common example:
 - amd64 ABI has one unshared header: gnu/stubs-64.h
 - x86 ABI has three unshared headers: gnu/stubs-32.h sys/elf.h sys/vm86.h

so the overhead we're talking about here is that nomultilib amd64 systems will 
have 3 additional headers installed, and nomultilib x86 systems will have one 
extra header.  i suspect the overhead will be very similar for all arches.

the reason for doing this is to try and make multilib migration simpler.  with 
this change in place, you should be able to "upgrade" from a nomultilib amd64 
profile to a multilib amd64 profile with:
	USE='-*' emerge sys-devel/gcc
	emerge sys-libs/glibc
	emerge sys-devel/gcc

still not as automatic as i'd like, but getting closer ...
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]