FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 12-07-2011, 10:41 PM
Mike Frysinger
 
Default {bi,multi}arch support for all x86/amd64/ppc/sparc systems

for those who cannot read minds:
[1] https://bugs.gentoo.org/349405
-mike
 
Old 12-08-2011, 01:12 AM
Duncan
 
Default {bi,multi}arch support for all x86/amd64/ppc/sparc systems

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
 
Old 12-08-2011, 01:40 AM
Ryan Hill
 
Default {bi,multi}arch support for all x86/amd64/ppc/sparc systems

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
 
Old 12-08-2011, 02:34 AM
Mike Frysinger
 
Default {bi,multi}arch support for all x86/amd64/ppc/sparc systems

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
 
Old 12-11-2011, 08:01 PM
Mike Frysinger
 
Default {bi,multi}arch support for all x86/amd64/ppc/sparc systems

committed:
http://sources.gentoo.org/eclass/toolchain.eclass?r1=1.509&r2=1.510
-mike
 
Old 01-27-2012, 08:00 PM
Mike Frysinger
 
Default {bi,multi}arch support for all x86/amd64/ppc/sparc systems

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
 

Thread Tools




All times are GMT. The time now is 05:38 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org