Andrew Gaffney wrote:
John Eckhart wrote:
I'm trying to build a generic stage1 using the
stage3-x86-2006.1.tar.bz2 as a seed and the 20070319 portage
snapshot. I can get all the way up to the building of glibc
(glibc-2.5 as per the portage snapshot), which fails with the
following error:
* i386 CHOSTs are no longer supported.
* Chances are you don't actually want/need i386.
* Please read http://www.gentoo.org/doc/en/change-chost.xml
!!! ERROR: sys-libs/glibc-2.5 failed.
I wonder how the release team is producing the stage1's for 2007.0.
Are they masking glibc-2.5 or have they moved the sub-architecture
for stage1-x86 to something newer like i586?
There is a build problem with glibc-2.5 for the i386 CHOST. Rather
than fix it (which would be a lot of work for virtually no benefit),
the minimum supported CHOST has been changed to i486. Just set 'chost:
i486-pc-linux-gnu' in your stage1.spec. Unless you're planning on
installing on an actual 386, this will work fine for 486 and up.
Andrew,
Thanks, that helps. I am also seeing another build error when
building nano for the stage 1. It appears that the stage2 and stage3
seeds from 2006.1 are built without unicode support in ncurses, yet nano
is trying to build with unicode.
I've attached my spec file, here is a summary:
building: stage1-x86
seed: stage2-x86-2006.1
snapshot: 20070319
catalyst: 2.0.3
I'm not sure if I did something wrong, or it's because I am using the
latest portage snapshot, etc. If the problem has to do with the snapshot
then I can think of a few ways to fix it: add -unicode to the nano use
flags, pull the unicode nano requirement when USE="build", add a command
in the stage1-chroot.sh to update the seed and rebuild curses with unicode.
Here is the excerpt from my build log:
...
configure: error:
*** UTF-8 support was requested, but insufficient UTF-8 support was
*** detected in your curses and/or C libraries. Please verify that your
*** slang was built with UTF-8 support or your curses was built with
*** wide character support, and that your C library was built with wide
*** character support.
!!! Please attach the following file when filing a report to
bugs.gentoo.org:
!!! /var/tmp/portage/app-editors/nano-2.0.3/work/nano-2.0.3/config.log
!!! ERROR: app-editors/nano-2.0.3 failed.
Call stack:
ebuild.sh, line 1614: Called dyn_compile
ebuild.sh, line 971: Called qa_call 'src_compile'
environment, line 1238: Called src_compile
nano-2.0.3.ebuild, line 44: Called econf '--bindir=/bin'
'--enable-color' '--enable-multibuffer' '--enable-nanorc' '--disable-wr
apping-as-root' '--disable-spell' '--disable-justify' '--disable-debug'
'--disable-nls' '--enable-utf8' '--disable-tiny' '--without-
slang'
ebuild.sh, line 577: Called die
!!! econf failed
!!! If you need support, post the topmost build error, and the call
stack if relevant.
!!! A complete build log is located at
'/var/tmp/portage/app-editors/nano-2.0.3/temp/build.log'.
!!! catalyst: run script failed.
Traceback (most recent call last):
File "modules/generic_stage_target.py", line 1047, in run_local
cmd("/bin/bash "+self.settings["controller_file"]+" run","run script
failed.",env=self.env)
File "/usr/lib/catalyst/modules/catalyst_support.py", line 485, in cmd
raise CatalystError,myexc
CatalystError: <unprintable instance object>
None
!!! catalyst: Stage build aborting due to error.
Catalyst aborting....
# generic installation stage specfile
# used to build a stage1, stage2, or stage3 installation tarball
# The subarch can be any of the supported catalyst subarches (like athlon-xp).
# Refer to the catalyst reference manual for suppurted subarches.
# http://www.gentoo.org/proj/en/releng/catalyst/reference.xml
# From the catalyst webpage:
# Target description: The stage1 tarball is a very minimal toolchain. It is
# the base required to complete a bootstrap. It should always be as generic
# as possible. If building stages for an architecture which supports both
# 2.4 and 2.6 kernels, one must build stage1 without NPTL enabled. The
# stage2 tarball is the output of the bootstrap sequence, using a limited
# subset of USE from the chosen profile. The stage3 tarball is the completed
# "system" target, which is defined by the profile used.
# example:
# subarch: athlon-xp
subarch: x86
# The version stamp is an identifier for the build. It can be anything you wish
# it to be, but it is usually a date.
# example:
# version_stamp: 2006.1
version_stamp: 20070320
# The target specifies what target we want catalyst to do. For stages, the
# supported targets are: stage1 stage2 stage3
# example:
# target: stage2
target: stage1
# The rel_type defines what kind of build we are doing. This is merely another
# identifier, but it useful for allowing multiple concurrent builds. Usually,
# default will suffice.
# example:
# rel_type: default
rel_type: default
# This is the system profile to be used by catalyst to build this target. It is
# specified as a relative path from /usr/portage/profiles.
# example:
# profile: default-linux/x86/2006.1
profile: default-linux/x86/2006.1
# This specifies which snapshot to use for building this target.
# example:
# snapshot: 2006.1
snapshot: 20070319
# This specifies where the seed stage comes from for this target, The path is
# relative to $clst_sharedir/builds. The rel_type is also used as a path prefix
# for the seed.
# example:
# default/stage3-x86-2006.1
source_subpath: 2006.1/stage2-x86-2006.1
# These are the hosts used as distcc slaves when distcc is enabled in your
# catalyst.conf. It follows the same syntax as distcc-config --set-hosts and
# is entirely optional.
# example:
# distcc_hosts: 127.0.0.1 192.168.0.1
# This is an optional directory containing portage configuration files. It
# follows the same syntax as /etc/portage and should be consistent across all
# targets to minimize problems.
# example:
# portage_confdir: /etc/portage
# This option specifies the location to a portage overlay that you would like to
# have used when building this target.
# example:
# portage_overlay: /usr/local/portage
# This allows the optional directory containing the output packages for
# catalyst. Mainly used as a way for different spec files to access the same
# cache directory. Default behavior is for this location to be autogenerated
# by catalyst based on the spec file.
# example:
# pkgcache_path: /tmp/packages
# These options are only available when building a stage1 or stage2 target and
# are all optional. These allow for emulating the changes possible during ai
# bootstrap. Some possible uses of these would be building embedded stages
# requiring a different CHOST or building a stage2 with NPTL support from a
# stage1 tarball that is built without it.
# If left blank, then the catalyst defaults from arch.py are used.
# This option is used to change the CHOST from what is default in the profile
# to whatever you specify. This is useful for building NPTL, for example.
# example:
# chost: i686-pc-linux-gnu
chost: i486-pc-linux-gnu
# This option allows you to change the default CFLAGS that will be used in
# building this stage. This really should remain generic, as putting
# optimizations flags here will build a stage1 tarball that is no longer
# generic.
# example:
# cflags: -Os -pipe -fomit-frame-pointer -mcpu=i686
# cflags:
# This is for setting the CXXFLAGS. Generally, this would be set to the same
# as CFLAGS. In fact, it will mirror CFLAGS by default.
# example:
# cxxflags: -Os -pipe -fomit-frame-pointer -mcpu=i686
# cxxflags:
# Setting this option sets LDFLAGS in make.conf in your stage. This would be
# useful for setting up an embedded or hardened system.
# example:
# ldflags: -Wl,-O1 -Wl,-z,now
# ldflags:
