Mailing List Archive

George Hedfors wrote:
> I've found out several times that I have to recompile perl manually
> during the "emerge -e system" process due to some error becouse perl
> was unable to locate the proper gcc.

Have you read our GCC Update Guide [1]?

> During the installation I change the CHOST in /etc/make.conf, which
> then changes the location of gcc according to gcc-config, but after
> this, perl has to be reinstalled for it to be able to compile modules
> properly.

Changing CHOST is a bit tricky. Setting it in /etc/make.conf is not
enough. You have to use the /usr/portage/scripts/bootstrap.sh script.

Anyway, how is this related to the documentation? :)

[1] http://www.gentoo.org/doc/en/gcc-upgrading.xml

Cheers,
-jkt

--
cd /local/pub && more beer > /dev/mouth

Well no, but I did this change before doing the actual bootstrap. I
followed the quick install guide and made changes to make.conf, then
completed bootstrap.sh and started emerging the system. Thats when it
happend. As there is a stage-installed perl version, when the library
tried to compile, it used the present perl version as it was dependent
on it. However, as the stage-installed version did'nt work with my
changes, i had to manually upgrade perl before i could emerge the rest
of the system. I'm sure other people will have the same problem and to
solve this, one way would be to reinstall perl somewhere in the very
beguinning of emerge system.

I'm just a stupid user trying to make life easier for others :).

Thanks, George.

On 5/11/06, Jan Kundrát <jkt@gentoo.org> wrote:
> George Hedfors wrote:
> > I've found out several times that I have to recompile perl manually
> > during the "emerge -e system" process due to some error becouse perl
> > was unable to locate the proper gcc.
>
> Have you read our GCC Update Guide [1]?
>
> > During the installation I change the CHOST in /etc/make.conf, which
> > then changes the location of gcc according to gcc-config, but after
> > this, perl has to be reinstalled for it to be able to compile modules
> > properly.
>
> Changing CHOST is a bit tricky. Setting it in /etc/make.conf is not
> enough. You have to use the /usr/portage/scripts/bootstrap.sh script.
>
> Anyway, how is this related to the documentation? :)
>
> [1] http://www.gentoo.org/doc/en/gcc-upgrading.xml
>
> Cheers,
> -jkt
>
> --
> cd /local/pub && more beer > /dev/mouth
>
>
>


--
PGP Fingerprint:
4BB9 7A99 3DB5 52AA 8CEF 4DFB 32F2 41AC 0EF2 D595

--
gentoo-doc@gentoo.org mailing list

On Thu, 2006-05-11 at 19:39 +0200, George Hedfors wrote:
> Well no, but I did this change before doing the actual bootstrap. I
> followed the quick install guide and made changes to make.conf, then
> completed bootstrap.sh and started emerging the system. Thats when it
> happend. As there is a stage-installed perl version, when the library
> tried to compile, it used the present perl version as it was dependent
> on it. However, as the stage-installed version did'nt work with my
> changes, i had to manually upgrade perl before i could emerge the rest
> of the system. I'm sure other people will have the same problem and to
> solve this, one way would be to reinstall perl somewhere in the very
> beguinning of emerge system.
>
> I'm just a stupid user trying to make life easier for others :).

While I understand and we truly do appreciate the input, this is
*exactly* why Release Engineering has dropped support for stage1 and
stage2 installs and recommend to everyone to use the stage3 tarballs for
*all* installations.

The stage3 tarball is a known-good minimal working system.

There are simply too many variables possible in doing a stage1 or stage2
installation that need to be addressed. I honestly should change the
end bootstrap.sh message to tell the user that if something breaks, they
get to pick up the pieces themselves. ;]

Gentoo has, unfortunately, become a victim of its own success. The more
flexibility we add to the system, the harder it is to test for multiple
scenarios that are possible when doing an installation. For some time
now, it has been simply impossible for us to test stage1 and stage2
installations with any degree of certainty that what builds on my
machine will build on yours. There's simply too many USE flags
affecting the "system" target. Also, most people don't realize that
"system" is 100% contrived by portage from the profile and its own
internal dependency calculations. We simply can't make something appear
sooner in the dependency tree than it already does, without editing the
ebuilds, which almost always has unforseen consequences, causing a
back-out.

Trust me. This is exactly what takes us so long during releases to get
going. It usually takes us a few weeks just to get the stages to build
properly, due to changes that have happened in the tree since the last
release.

If you want an installation that actually *works*, use a stage3 tarball.
If you're familiar with the concepts of bootstrapping and are
comfortable with cleaning up after portage vomiting all over your system
because of something that changed in the time since release and you
doing your installation, feel free to use the lower stages. Personally,
I *always* use a stage3 installation now. Most of the time, I use GRP.
I hate waiting to get a usable system. I'd much rather be checking my
email and letting a compile go on in the background than stare at a
console of scrolling text and not be able to do much but ssh to another
box or chat on IRC for days.

--
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

I understand guys and I think you are doing a great job. I've
personally used Linux since the end of 1994, started off with
Slackware but during the later years been using various dists of BSD
instead. However, I recently found the joy in Gentoo and have now been
using it for the last 6 months on a number of servers and other
machines. Just want to give my input and i really appreciate the
response I've been given here. Keep up the good work guys!

On 5/11/06, Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> On Thu, 2006-05-11 at 19:39 +0200, George Hedfors wrote:
> > Well no, but I did this change before doing the actual bootstrap. I
> > followed the quick install guide and made changes to make.conf, then
> > completed bootstrap.sh and started emerging the system. Thats when it
> > happend. As there is a stage-installed perl version, when the library
> > tried to compile, it used the present perl version as it was dependent
> > on it. However, as the stage-installed version did'nt work with my
> > changes, i had to manually upgrade perl before i could emerge the rest
> > of the system. I'm sure other people will have the same problem and to
> > solve this, one way would be to reinstall perl somewhere in the very
> > beguinning of emerge system.
> >
> > I'm just a stupid user trying to make life easier for others :).
>
> While I understand and we truly do appreciate the input, this is
> *exactly* why Release Engineering has dropped support for stage1 and
> stage2 installs and recommend to everyone to use the stage3 tarballs for
> *all* installations.
>
> The stage3 tarball is a known-good minimal working system.
>
> There are simply too many variables possible in doing a stage1 or stage2
> installation that need to be addressed. I honestly should change the
> end bootstrap.sh message to tell the user that if something breaks, they
> get to pick up the pieces themselves. ;]
>
> Gentoo has, unfortunately, become a victim of its own success. The more
> flexibility we add to the system, the harder it is to test for multiple
> scenarios that are possible when doing an installation. For some time
> now, it has been simply impossible for us to test stage1 and stage2
> installations with any degree of certainty that what builds on my
> machine will build on yours. There's simply too many USE flags
> affecting the "system" target. Also, most people don't realize that
> "system" is 100% contrived by portage from the profile and its own
> internal dependency calculations. We simply can't make something appear
> sooner in the dependency tree than it already does, without editing the
> ebuilds, which almost always has unforseen consequences, causing a
> back-out.
>
> Trust me. This is exactly what takes us so long during releases to get
> going. It usually takes us a few weeks just to get the stages to build
> properly, due to changes that have happened in the tree since the last
> release.
>
> If you want an installation that actually *works*, use a stage3 tarball.
> If you're familiar with the concepts of bootstrapping and are
> comfortable with cleaning up after portage vomiting all over your system
> because of something that changed in the time since release and you
> doing your installation, feel free to use the lower stages. Personally,
> I *always* use a stage3 installation now. Most of the time, I use GRP.
> I hate waiting to get a usable system. I'd much rather be checking my
> email and letting a compile go on in the background than stare at a
> console of scrolling text and not be able to do much but ssh to another
> box or chat on IRC for days.
>
> --
> Chris Gianelloni
> Release Engineering - Strategic Lead
> x86 Architecture Team
> Games - Developer
> Gentoo Linux
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
>
> iD8DBQBEY6cikT4lNIS36YERAny5AJ4+UusF/DLMqrXE89+weO553GwOAACffEM2
> ys4evBo0BhI1p4xKSq0mH8c=
> =XEFZ
> -----END PGP SIGNATURE-----
>
>
>


--
PGP Fingerprint:
4BB9 7A99 3DB5 52AA 8CEF 4DFB 32F2 41AC 0EF2 D595

--
gentoo-doc@gentoo.org mailing list