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