public inbox for gentoo-mips@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Stephen P. Becker" <geoman@gentoo.org>
To: gentoo-mips@lists.gentoo.org
Subject: [gentoo-mips] profiles
Date: Tue, 30 Aug 2005 11:18:51 -0400	[thread overview]
Message-ID: <431478DB.6090404@gentoo.org> (raw)
In-Reply-To: <20050813101402.GL30724@puck.ch>

Hi folks,

With the somewhat recent introduction of support for a wide variety of 
SGI machines under gentoo, expanding to include all of Indy/Indigo2, 
Origin, Octane, Indigo2 Impact (ip28), and O2, I've noticed more than 
just a handful of new users have had problems when getting to the kernel 
compile phase of the install.  The problem is that on systems that only 
run 64-bit kernels, you need a mips64-unknown-linux-gnu toolchain to 
build the kernel.  Since the userland is all 32-bit, the native 
toolchain isn't good enough to compile the kernel.  However, we do 
provide a proper toolchain via the gcc-mips64 ebuild.  Furthermore, 
binutils supports mips64 by default, but symlinks must exist such that 
we have mips64-unknown-linux-gnu-ld -> ld, etc.  Both of these are 
automatically provided during emerge system if you use the correct 
profile, which is default-linux/mips/mips64/2005.0 currently.

The problem is that all of our stages ship with 
default-linux/mips/2005.0 as the default profile, which does *not* 
provide gcc-mips64 and the binutils symlinks.  Therefore if a user 
didn't know any better and didn't change their profile appropriately, 
they would be stuck while trying to build their kernel because the 
native 32-bit toolchain in the userland will just spit out errors and 
die when compiling the kernel.  Of course, this is easily fixed by 
emerging gcc-mips64 and running "binutils-config --mips", which will set 
up a proper toolchain.  However, by that time, the user is discouraged a 
bit and inevitably finds our irc channel and whines that Gentoo is broken.

Now, I have a few ideas for getting around this.  Obviously whatever is 
decided should be added to the documentation, but here are some ideas:

A) Do nothing...document in the handbook that if your machine is 64-bit, 
you *must* select the mips64 sub-profile. (I don't like this because 
some folks may be confused as to why everything still works just fine 
with the mips profile, and/or they will just skim over that and keep going)

B) Similar to A, except ship stages without the profile set.  That way, 
folks really are stuck until they set the proper profile.  (I don't like 
this because they could still be confused and set the mips profile)

C) Make default-linux/mips/ provide all the 64-bit stuff and get rid of 
the mips64 sub-profile, since all of the SGI machines we support can run 
64-bit kernels if you so choose (ip22 is the only system that supports a 
32-bit kernel at this time).

D) (Kumba's idea here...) Have machine specific profiles, e.g. 
default-linux/mips/ip22, default-linux/mips/ip32, etc.  (This could be 
really useful because it would allow us to do some other machine 
specific voodoo in the profile).

Any thoughts?

-Steve
-- 
gentoo-mips@gentoo.org mailing list



  reply	other threads:[~2005-08-30 15:19 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-08 11:59 [gentoo-mips] IP30 hang on warm boot Aaron Walker
2005-08-11 20:05 ` Olivier Bornet
2005-08-11 22:22   ` Aaron Walker
2005-08-12  6:47     ` Olivier Bornet
2005-08-12 12:31       ` Aaron Walker
2005-08-13 10:14         ` Olivier Bornet
2005-08-30 15:18           ` Stephen P. Becker [this message]
2005-08-30 16:47             ` [gentoo-mips] profiles Curtis Phillips
2005-09-01  1:49               ` Stuart Longland
2005-09-01 11:00                 ` Stephen Bennett
2005-09-01 14:22                   ` Stuart Longland
2005-09-01 14:30                     ` Stephen Bennett
2005-09-01 12:12             ` Stephen Bennett
2005-09-03  2:05             ` Kumba

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=431478DB.6090404@gentoo.org \
    --to=geoman@gentoo.org \
    --cc=gentoo-mips@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox