Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 88777 - python-fchksum missing dependancy during emerge -e system
Summary: python-fchksum missing dependancy during emerge -e system
Status: VERIFIED TEST-REQUEST
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Python Gentoo Team
URL:
Whiteboard:
Keywords:
: 89009 89541 91949 96641 97233 102492 102781 102898 103820 105514 105515 105983 107457 107496 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-04-11 15:07 UTC by jon R-B
Modified: 2007-04-18 17:23 UTC (History)
21 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description jon R-B 2005-04-11 15:07:00 UTC
This came to light while doing "Bob P" Stage 3/1 2005.0 install
I got an error while doing the emerge -e system (with an i686 gcc installed) that while trying to emerge "python-fchksum" it could not find the i386 gcc

Basically in the "emerge -e system" python-fchksum was being emergeed before python. Shouldn't python-fchksum depend on python?

In the ebuild for python-fchksum it states?

QUOTE

# Copyright 1999-2004 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/dev-python/python-fchksum/python-fchksum-1.6.1-r1.ebuild,v 1.25 2004/12/14 09:45:23 eradicator Exp $

# DON'T inherit distutils because it will cause a circular dependency with python
#inherit distutils

DESCRIPTION="Python module to find the checksum of files"
SRC_URI="http://www.dakotacom.net/~donut/programs/fchksum/${P}.tar.gz"
HOMEPAGE="http://www.dakotacom.net/~donut/programs/fchksum.html"

KEYWORDS="amd64 x86 ppc sparc alpha hppa mips ia64"
LICENSE="GPL-2"
SLOT="0"
IUSE=""

DEPEND="sys-libs/zlib"

src_compile() {
   python setup.py build || die
}

src_install() {
   python setup.py install --root=${D} || die
} 


Note in the DEPEND no mention of python, but python is use ni the src_compile/install.

What if python was unmerged (by accident) and someone tried to emerge "python-fchksum" it would fail on trying to find the command "python", IF python was stated in the DEPEND, then python would be pulled in first.

This also would correct a few ppl who have had this problem with the (unsupported by Gentoo) stage 3/1 2005 install

Reproducible: Always
Steps to Reproduce:
1.
2.
3.
Comment 1 Rob Cakebread (RETIRED) gentoo-dev 2005-04-11 17:06:01 UTC
Could you explain what this is please: "Bob P" Stage 3/1 2005.0 

If someone ignores the warning about removing Python, I don't see how adding python to the DEPEND on this would change anything. Please clarify.
Comment 2 Rob Cakebread (RETIRED) gentoo-dev 2005-04-11 17:24:43 UTC
If you see what you pasted it says there is a circular dependency, so we can't add Python to the DEPEND. Closing.
Comment 3 jon R-B 2005-04-12 02:13:40 UTC
mmm strange my reply didnt get posted this morning.
Sorry,

anyway this bug (of sorts) was posted last night when I was a bit drunk

Basically If you do a "emerge -e system" python-fscksum gets emerged before python.

Now If you went an upgraded your compiler (say you were on i386 and not i686) Python is hardcoded with the compiler version it was compiled with.

If you then did the emerge -e system (or even just emerge python-fscksum) it would complain because it cannot find i386-gcc

just a small thing and I can see the cyclic reducnacy thing ( now ) sorry for the waste of time

Jon
Comment 4 Yuri Vasilevski (RETIRED) gentoo-dev 2005-06-09 16:22:53 UTC
Hi,

Today I studied the how python's distutils module work to see if I could resolve
the bug of dev-python/python-fchksum not emerging when doing emerge -e system
right after uclibc's stage1 scripts/bootstrap.sh. And the problem can be resumed
in the following:

1) Because of the current dependencies between python and python-fchksum,
python-fchksum is emerged before python with emerge -e system.
2) python-fchksum uses setup.py to build, which uses the distutils module. And
this module configures the build process to use exactly the same compiler and
linker as the ones that were used to build python.
3) In stage1-x86-uclibc-2005.0 was compiled with "CC=
i386-gentoo-linux-uclibc-gcc -pthread" which is an invalid compiler if CHOST=
was changed before running scripts/bootstrap.sh in stage1.

(2) definitely makes a lot of sense, so it should stay the way it is. (There is
a way to pass CC, CXX (and starting form python 2.4 LDSHARED) to setup.py, but I
think it's a very bad idea for modules.)

(3) It is a very common situation to change CHOST in stage1, but this does not
affect some other stage1 tar.bz2s as their python was compiled with "CC= gcc
-pthread" (this is the case of stage1-x86-2005.0 and stage1-x86-uclibc-2004.3),
but I think it's not the way to go as this just uses the assumption that there
will always be a working "gcc" to do the work instead of solving the problem.
Also this will make portage behave badly in case there will ever be support for
crosscompilation.

(1) I think that this is the way to attack this problem. First of all, this does
not create a circular dependency (not at all like openssl <-> python). So I
think dev-python/python-fchksum should DEPEND on dev-lang/python and
dev-lang/python should PDEPEND on dev-python/python-fchksum. In this case all
the real dependencies should be in it's place (I'll fundament this in
"Additional Info") and emerge should emerge them in the right order (I'll test
this later and comment).

Additional Info:

Form Comment #1 we can see that dev-python/python-fchksum to be build.

Form dev-lang/python/python-*.ebuild:

# NOTE: The dev-python/python-fchksum RDEPEND is needed so that this python 
#       provides the functionality expected from previous pythons.

# NOTE: python-fchksum is only a RDEPEND and not a DEPEND since we don't need
#       it to compile python. We just need to ensure that when we install
#       python, we definitely have fchksum support. - liquidx

From $ man 5 ebuild:
       DEPEND This should contain a list of all packages that are required for
              the program to compile.

       RDEPEND
              This should contain a list of all packages that are required for
              this  program  to run (aka runtime depend).  If this is not set,
              then it defaults to the value of DEPEND.
              You may use the same syntax to vary dependencies as  seen  above
              in DEPEND.

       PDEPEND
              This  should contain a list of all packages that will have to be
              installed after the program has been merged.
              You may use the same syntax to vary dependencies as  seen  above
              in DEPEND.

And with respect to the python-fchksum compilation problem:

>>> Source unpacked.
['setup.py', 'build']
running build
running build_ext
building 'fchksum' extension
creating build
creating build/temp.linux-i686-2.3
i386-gentoo-linux-uclibc-gcc -pthread -fno-strict-aliasing -DNDEBUG
-march=pentium4 -O3 -pipe -fPIC 
-I/usr/include/python2.3 -c md5.c -o build/temp.linux-i686-2.3/md5.o
gcc-config error: Could not run/locate "i386-gentoo-linux-uclibc-gcc"
error: command 'i386-gentoo-linux-uclibc-gcc' failed with exit status 1

!!! ERROR: dev-python/python-fchksum-1.7.1 failed.
!!! Function src_compile, Line 20, Exitcode 1
!!! (no error message)
!!! If you need support, post the topmost build error, NOT this status message.

Yuri.
Comment 5 Alastair Tse (RETIRED) gentoo-dev 2005-06-10 08:10:18 UTC
good analysis of the possible solution here. PDEPEND is a little strange for my liking. i've used it before 
and it has caused more headaches than it has solved (see: openjade and opensp).

if we can prove that it doesn't fail for GRP, Stage 1 & 2 building and emerge -e system, then i'd be happy 
to accept that change. 

on further analysis of the problem, missing fchksum for some parts of building is alright because 
portage_checksum.py has a fallback function if fchksum isn't found. thats very nice. in fact, i sometimes 
think that it should be sys-apps/portage that should have fchksum dependency and not python. but 
there's too much legacy here that i don't want to touch :)
Comment 6 Yuri Vasilevski (RETIRED) gentoo-dev 2005-06-20 12:55:32 UTC
I tested the fallback function and it isn't enough for portage to work correctly
(it looks like it works but on emerge -e system from stage1 to stage2 it just
restarts the whole emerge after emerging portage instead of continuing), so
python-fchksum definitely needs to be in portage DEPEND.

Then I made another two tests. One without python-fchksum in python's *DEPEND at
all, and another with python-fchksum in python's PDEPEND. And they both behaved
in the correct way with respect to emerge -e system (the order was python, then
python-fchksum and then portage).
And the good thing is that it worked fine with uclibc's stage1.

So I also think the best solution will be to remove python-fchksum from python's
*DEPEND, but I don't know how many packages there are that really depend on
python-fchksum while they don't have it in *DEPEND. And if there are many of
them I'm sure they'll be hard to track as python-fchksum should definitely be
installed as portage's dependency. So it may make sense to just change it to be
in python's PDEPEND.

Let me know if you want me to do any GRP/stages tests. And of you do, where can
I get the official catalyst scripts to make the tests with.

Yuri.
Comment 7 Jakub Moc (RETIRED) gentoo-dev 2005-06-27 10:54:53 UTC
*** Bug 97233 has been marked as a duplicate of this bug. ***
Comment 8 Jakub Moc (RETIRED) gentoo-dev 2005-06-27 10:55:50 UTC
*** Bug 91949 has been marked as a duplicate of this bug. ***
Comment 9 Tom Gall (RETIRED) gentoo-dev 2005-07-01 19:37:28 UTC
This is fixable .... as the bug here is quite quite evil

as it turns out when python builds some sort of "compile" object to actually DO
the build, it's pulling in values from the prior i386-...-gcc build of python.
Evil! Evil! Evil!

I've found that the python code DOES respect the setting of CC!

so simply said, export CC gets the .c->.o build step to work

The link step for the library however ... well this is where one needs their
lightsabre and full jedi powers.

The link step CC value setting obscure it is. Uses strange place to grab CC
setting it does. Respect CC environment variable it does not. 

/usr/lib/python2.3/config/Makefile getting CC value from it is. 

Yoda help!

More as I figure it out.....
Comment 10 Yuri Vasilevski (RETIRED) gentoo-dev 2005-07-01 19:53:46 UTC
python 2.4 respects the LDSHARED (it's value is used as the program to link the
module) environment variable, python 2.3 does not (see
/usr/lib/python2.{3,4}/distutils/sysconfig.py).

But I still think that it is reasonable/sane to build python modules with the
same settings as python itself and as this is a dependencies issue I think it
should be resolved in that area without any non logical workaround (like
changing CC and LDSHARED).

Yuri.
Comment 11 Jakub Moc (RETIRED) gentoo-dev 2005-07-07 10:30:02 UTC
Reopening. Per recent conversation on #gentoo-dev this is not dependencies
issue, the explanation in comment #9 is correct.
Comment 12 Devils-Hawk 2005-08-07 09:56:48 UTC
stage1-x86-2005.1_pre1 is showing the same problems, this should probably be
fixed before the release.
Comment 13 Henrik Brix Andersen 2005-08-11 14:26:17 UTC
So currently no work-around exists for python2.3? Setting CC= resolves the
compile phase, but not the link phase...
Comment 14 Henrik Brix Andersen 2005-08-11 15:13:05 UTC
FYI: I temporarily changed CC=gcc in /usr/lib/python2.3/config/Makefile and got
it to go past the link stage with emerge --resume.
Comment 15 Davide Andrea 2005-08-12 09:21:32 UTC
Same here. Same error, same workaround. 
Comment 16 scott j. lopez 2005-08-13 07:31:12 UTC
sad to say. but this bug just hit me in 2005.1 release when installing on a new pentium4 system. the 
workaround listed in comment #14 worked, but on would hope this was fixed before a release. does it 
affect all new installs or just on rare occasions?
Comment 17 Henrik Brix Andersen 2005-08-13 07:33:28 UTC
As far as I can tell, it affects all stage1 installations where the user changes
CHOST.
Comment 18 Wolfram Schlich (RETIRED) gentoo-dev 2005-08-13 13:12:36 UTC
Exactly, and chaning CHOST is what almost all stage1 users do :-)
Comment 19 SpanKY gentoo-dev 2005-08-14 19:54:35 UTC
*** Bug 102492 has been marked as a duplicate of this bug. ***
Comment 20 Martin LORANG 2005-08-15 01:13:56 UTC
Same here. Comment #14 worked for me.
2005.1 stage1 install
~x86
Comment 21 Daniel Lynch 2005-08-15 21:51:27 UTC
I performed a test at the request of kloeri for a fix he proposed. Everything
worked out fine.
Steps I took:
1) Used stage1 x86 2005.1 tarball
2) Edited make.conf and changed CHOST from i386 to i686
3) Added USE="python"
4) Edited the dev-lang/python-2.3.5.ebuild and changed:
RDEPEND="${DEPEND} dev-python/python-fchksum"
to:
PDEPEND="${DEPEND} dev-python/python-fchksum"
5) Bootstrapped and did 'emerge -e system'

Everything built with no problems.
Comment 22 Bryan Østergaard (RETIRED) gentoo-dev 2005-08-16 01:26:56 UTC
Fixed in ~arch. I'll add the fix to arch in ~12 hours if no weird bug reports
show up.
Comment 23 Christopher Frömmel 2005-08-16 05:51:40 UTC
2005.1 stage 1. fix does work. strange bug, but it is even more strange, that
this has come to 2005.1 final...
Comment 24 Chris Gianelloni (RETIRED) gentoo-dev 2005-08-16 06:45:43 UTC
Not really...  We don't go around changing CHOST, as there's no benefit to doing
so, other than not seeing a "i386" when doing merges and such.

Anyway, I'm glad to see that it will be resolved.  Luckily, it only affects
stage1 builds, so once this hits the tree, it'll fix it for everyone.
Comment 25 Bryan Østergaard (RETIRED) gentoo-dev 2005-08-16 15:12:19 UTC
This is not really a bug in the stages and I'm pretty sure you'll hit the bug
even with older stages..

That said, I just added the fix to stable versions of python and the fix should
hit rsync mirrors in a few hours.
Comment 26 Andrew Gaffney (RETIRED) gentoo-dev 2005-08-16 19:50:31 UTC
*** Bug 102781 has been marked as a duplicate of this bug. ***
Comment 27 Jakub Moc (RETIRED) gentoo-dev 2005-08-17 13:57:19 UTC
*** Bug 102898 has been marked as a duplicate of this bug. ***
Comment 28 SpanKY gentoo-dev 2005-08-17 21:17:05 UTC
*** Bug 89541 has been marked as a duplicate of this bug. ***
Comment 29 Robin Kauffman 2005-08-22 00:48:02 UTC
I ran into this error again when prograssing from a Stage2->Stage3.  I started
with an x86 Stage1 (changed CHOST to i686-pc-linux-gnu) and a portage tree that
was current as of today (8/21/05).  When running 'emerge -e system' on the
stage2 I encountered the same error as described above.  The system tries to
compile python-fchksum with i386-pc-linux-gnu-gcc and gcc-config can't find it.
 Bryan 
Comment 30 Robin Kauffman 2005-08-22 00:48:02 UTC
I ran into this error again when prograssing from a Stage2->Stage3.  I started
with an x86 Stage1 (changed CHOST to i686-pc-linux-gnu) and a portage tree that
was current as of today (8/21/05).  When running 'emerge -e system' on the
stage2 I encountered the same error as described above.  The system tries to
compile python-fchksum with i386-pc-linux-gnu-gcc and gcc-config can't find it.
 Bryan Østergaard said that a fix had been committed to the stable ebuild for
python, but I certainly don't seem to be reaping its benifits.
Comment 31 Robin Kauffman 2005-08-22 02:06:41 UTC
Oh yes -- here is my 'emerge info' since I've unmasked GCC 3.4.4:
Portage 2.0.51.22-r2 (default-linux/x86/2005.1, gcc-3.4.4, glibc-2.3.5-r1,
2.6.12-gentoo-r6 i686)
=================================================================
System uname: 2.6.12-gentoo-r6 i686 Unknown CPU Type
Gentoo Base System version 1.6.13
dev-lang/python:     2.3.5
sys-apps/sandbox:    1.2.11
sys-devel/autoconf:  2.13, 2.59-r6
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5
sys-devel/binutils:  2.15.92.0.2-r10
sys-devel/libtool:   [Not Present]
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config
/usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/splash /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks sandbox sfperms strict"
GENTOO_MIRRORS="http://gentoo.osuosl.org"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://rsync.us.gentoo.org/gentoo-portage"
USE="x86 X aac aalib acl acpi aim alsa arts audiofile avi bash-completion berkdb
bitmap-fonts bluetooth bonobo bzip2 cdr crypt cups curl doc dvd dvdr dvdread eds
emboss encode evo fam fastcgi ffmpeg foomatic foomaticdb fortran gcj gdbm gif
gnome gnutls gpm gps gstreamer gtk gtk2 gtkhtml icq imlib ipv6 jabber jack jpeg
kde libg++ libwww mad maildir mikmod mime mmx mng motif mp3 mpeg msn mysql
mysqli nas ncurses nls nptl ocaml offensive ogg oggvorbis openal opengl oscar
oss pam pdflib perl php png postgres ppds python qt quicktime readline ruby
samba scanner sdl spell sse ssl svg svga tcpd theora truetype truetype-fonts
type1-fonts usb vorbis wifi wmf wxwindows xml2 xmms xprint xv xvid yahoo zlib
userland_GNU kernel_linux elibc_glibc"
Unset:  ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY
Comment 32 Bryan Østergaard (RETIRED) gentoo-dev 2005-08-22 14:56:42 UTC
Robin, what does the cvs header line of dev-lang/python/python-2.3.5.ebuild say?
If it doesn't say v1.22 (or later) it isn't fixed and you need to update your
portage tree.

As there's been an issue lately with some RSYNC mirrors you might want to leave
out SYNC=.. from /etc/make.conf while updating your portage tree.
Comment 33 Chris Gianelloni (RETIRED) gentoo-dev 2005-08-23 06:23:21 UTC
*sigh*

Why do people insist on changing their CHOST setting anyway?

I'm very interested in knowing if this is fixed in newer versions, so please
report back to this bug if this resolves the issue for you.
Comment 34 Jakub Moc (RETIRED) gentoo-dev 2005-08-26 05:37:17 UTC
*** Bug 103820 has been marked as a duplicate of this bug. ***
Comment 35 Robin Kauffman 2005-09-01 14:00:41 UTC
The version number of the current stable python ebuild is 1.22 on my system.
Comment 36 Jakub Moc (RETIRED) gentoo-dev 2005-09-10 11:54:15 UTC
*** Bug 105515 has been marked as a duplicate of this bug. ***
Comment 37 Jakub Moc (RETIRED) gentoo-dev 2005-09-10 11:54:24 UTC
*** Bug 105514 has been marked as a duplicate of this bug. ***
Comment 38 eric van leeuwen 2005-09-10 12:50:43 UTC
My ebuild seems to already have the RDEPEND changed to PDEPEND but its still 
producing this error, after i applied the "USE" flag it still shows it coming 
after dev-python/python-fchksum. what would happen if i simply emerged python 
before the emerge -e system?
Comment 39 Lex 2005-09-11 08:53:01 UTC
I had the same problem. 
 
Yesterday I started a stage1 install, and I changed CHOST to i686-pc-linux-gnu 
 
When I emerged python, and then tried to emerge python-fchksum, it worked. 
 
~Lex 
Comment 40 Josh Perry 2005-09-11 11:30:02 UTC
I had the same issue today going from stage1 - stage2
emerge -e system

I changed the line in /usr/lib/python2.3/config/Makefile along the lines of
comment #14, from

CC=i386-pc-linux-gnu-gcc -pthread

to

CC=i386-pc-linux-gnu-gcc -pthread

this let the emerge continue with emerge --resume, but really its just a hack.

Responding to comment #32: Gentoo is about choice, and I choose to change my
CHOST setting!
Comment 41 Josh Perry 2005-09-11 11:32:58 UTC
Sorry, should have been

CC=i386-pc-linux-gnu-gcc -pthread

to

CC=i686-pc-linux-gnu-gcc -pthread
Comment 42 Chris Gianelloni (RETIRED) gentoo-dev 2005-09-12 05:32:19 UTC
(In reply to comment #39)
> Responding to comment #32: Gentoo is about choice, and I choose to change my
> CHOST setting!

No, it isn't.  Gentoo is about *empowering* the user to make choices.  We don't
allow choice for the simple sake of choice, otherwise we would have a convoluted
mass of nonworking junk.  Basically, if you're changing your CHOST settings,
*AGAINST THE ADVICE OF THE DEVELOPERS*, which is nothing more than a *COSMETIC*
change anyway, then you should be willing and knowledgeable enough to pick up
the pieces when it vomits all over your system.  Now, we're working to "fix"
this "problem" for the people that *insist* on maintaining a broken behavior,
but it has nothing to do with "choice" or any lack thereof and more to do with
protecting our users from themselves.

All of that being said, I modifed catalyst to use CHOST=i686-pc-linux-gnu by
default, so the stage1 tarballs will have that as a default now.  This should
appease everyone who thinks a directory being named i386* actually affects their
system in any way. ;]
Comment 43 Frank 2005-09-13 05:29:31 UTC
(In reply to comment #40)
> Sorry, should have been
> 
> CC=i386-pc-linux-gnu-gcc -pthread
> 
> to
> 
> CC=i686-pc-linux-gnu-gcc -pthread

Hmmm, that won't work for people with an i586. What about changing it to:

CC=${CHOST}-gcc

Just a thought.

BTW: the python-fchksum.ebuild calls ``python setup.py''.
If I do an:
find / -name setyp.py
I get
/usr/portage/app-emacs/python-mode/files/setup.py
/usr/portage/dev-python/reportlab/files/1.14/setup.py
/usr/portage/dev-python/reportlab/files/1.17/setup.py
/usr/portage/dev-python/formkit/files/0.6.1/setup.py

Which of these setup.py the ebuild uses?

Well, and yes, if python is installed BEFORE emerge system the build don't fail.
Comment 44 Yassen Damyanov 2005-09-13 07:07:34 UTC
As a noob that reads and follows the Handbook,
need to ask Chris for an explanation on Comment #41:

> if you're changing your CHOST settings,
> *AGAINST THE ADVICE OF THE DEVELOPERS*

I am not a native speaker so it might be my fault
misunderstanding the Handbook, but IMHO there is no any
notion anywhere there that stage1 users are advised *not
to* change the CHOST variable. Or do I miss something?

> which is nothing more than a *COSMETIC* change anyway

That sounds nice; well, why isn't this in the Handbook as well?
Instead, we have this:

  "The CHOST variable defines what architecture gcc has to
  compile programs for."

Does it sound strange then that people decide to use stage1
*so that they can change CHOST* ??

Finally, my stage1 installation just failed with this
same error, wasting hours of my time and this really
kills me as I am in a situation where I don't have
plenty of it.

Sadly, the bug is indeed frustrating for many users
(check the forums for python-fchksum), but for me
the attitude of Comment #41 is *hundred times* more
frustrating. This is the kind of attitude I was trying
to escape from, that brought me to Gentoo.
Comment 45 Chris Gianelloni (RETIRED) gentoo-dev 2005-09-13 08:06:54 UTC
(In reply to comment #42)
> BTW: the python-fchksum.ebuild calls ``python setup.py''.
> If I do an:
> find / -name setyp.py
> I get
> /usr/portage/app-emacs/python-mode/files/setup.py
> /usr/portage/dev-python/reportlab/files/1.14/setup.py
> /usr/portage/dev-python/reportlab/files/1.17/setup.py
> /usr/portage/dev-python/formkit/files/0.6.1/setup.py
> 
> Which of these setup.py the ebuild uses?

None of them.  It uses the one in the python-fchksum tarball.
Comment 46 Chris Gianelloni (RETIRED) gentoo-dev 2005-09-13 08:14:52 UTC
(In reply to comment #43)
> > if you're changing your CHOST settings,
> > *AGAINST THE ADVICE OF THE DEVELOPERS*
> 
> I am not a native speaker so it might be my fault
> misunderstanding the Handbook, but IMHO there is no any
> notion anywhere there that stage1 users are advised *not
> to* change the CHOST variable. Or do I miss something?

You're correct.  This is not listed in the Handbook.  I will ask them to change
this now so there won't be any confusion.  I also noticed that the
make.conf.example has been changed from "# DO NOT CHANGE THIS SETTING UNLESS YOU
KNOW WHAT YOU ARE DOING!" to "# DO NOT CHANGE THIS SETTING UNLESS YOU ARE USING
STAGE1!" for the CHOST description, so I apologise that this valuable piece of
information has become lost to users.

> > which is nothing more than a *COSMETIC* change anyway
> 
> That sounds nice; well, why isn't this in the Handbook as well?
> Instead, we have this:
> 
>   "The CHOST variable defines what architecture gcc has to
>   compile programs for."
> 
> Does it sound strange then that people decide to use stage1
> *so that they can change CHOST* ??

Architecture is not the same as sub-architecture.  Anything i386 or i686 is all
the same architecture.  If you were to change this to something like
ppc-unknown-linux-gnu, then you would be changing the architecture.  Again, I'll
file bugs to have this text adjusted so it is less ambiguous.

> Finally, my stage1 installation just failed with this
> same error, wasting hours of my time and this really
> kills me as I am in a situation where I don't have
> plenty of it.

I'm sorry to hear that, but this is not my fault.  You could have easily chosen
a stage3 installation and saved yourself a good number of hours in doing your
installation.  In fact, doing a stage3 installation, making changes to
make.conf, performing an "emerge sync" and running an "emerge -e world && emerge
-v depclean" is faster than doing a stage1 installation, with the same net
result.  I'm also going to make sure that this is documented quite well in the
Handbook, as many users are under the impression that a stage1 actually gives
them *any* form of positive outcome.  The truth is that it is a complete waste
of time for anyone not doing extensive changes to their system and massive
customizations (like those not available via portage itself) and honestly should
not be recommended to *any* user.

> Sadly, the bug is indeed frustrating for many users
> (check the forums for python-fchksum), but for me
> the attitude of Comment #41 is *hundred times* more
> frustrating. This is the kind of attitude I was trying
> to escape from, that brought me to Gentoo.

There was no attitude given.  I was simply using changes in writing style to
point out things that are more important.  As a non-English speaker, I can
understand that you might interpret this wrongly.
Comment 47 Chris Gianelloni (RETIRED) gentoo-dev 2005-09-13 08:22:09 UTC
Bug #105809
Comment 48 Yassen Damyanov 2005-09-13 18:26:56 UTC
Chris: thank you for the calm reply and for your apology 
(which is quite appropriate in a case when following the
advice of the documentation brings to a broken build.)

I'll comment the technical issues within the new bug.

Good luck!

P.S. Many an open source project turned into cold war between
developers and users. But if it was up to me, I would say
that 'Gentoo is all about attitude'. I have always been
welcomed and appreciated, and I've tried to return the same
back. Sometimes things break, but I value good attitude more
than that. So let us try to keep Gentoo as an island of good
will for a little longer. Cheers!
Comment 49 Bryan Østergaard (RETIRED) gentoo-dev 2005-09-14 11:05:53 UTC
*** Bug 105983 has been marked as a duplicate of this bug. ***
Comment 50 Chris Slycord 2005-09-14 11:41:46 UTC
Everyone is saying that changing CHOST is just for "cosmetics." But when I've 
tried installing glibc with nptl it requires a minimum CHOST value and would 
not accept using i386. So unless the devs that support glibc just did that 
arbitrarily, there seems to be something more than "cosmetics."

Also, couldn't this problem be fixed by just adding dev-lang/python to the end 
of bootstrap.sh? This would avoid everything that depends on python that was 
compiled for a specific CHOST.
Comment 51 Chris Gianelloni (RETIRED) gentoo-dev 2005-09-15 06:44:39 UTC
(In reply to comment #49)
> Everyone is saying that changing CHOST is just for "cosmetics." But when I've 
> tried installing glibc with nptl it requires a minimum CHOST value and would 
> not accept using i386. So unless the devs that support glibc just did that 
> arbitrarily, there seems to be something more than "cosmetics."

It's arbitrary.  Changing CHOST has no effect other than changing the location
of the toolchain files.

> Also, couldn't this problem be fixed by just adding dev-lang/python to the end 
> of bootstrap.sh? This would avoid everything that depends on python that was 
> compiled for a specific CHOST.

Stage size is the primary concern here.  We don't want them getting bigger. 
Besides, that is treating the symptom, not the problem.
Comment 52 SpanKY gentoo-dev 2005-09-17 15:58:16 UTC
*** Bug 96641 has been marked as a duplicate of this bug. ***
Comment 53 Grant Goodyear (RETIRED) gentoo-dev 2005-09-17 20:29:06 UTC
Um, I could be wrong, but doesn't portage automatically use the built-in md5 if
"import fchksum" fails?  Thus, it should be possible to have python-fchksum in
system depending on python, and not a PDEPEND of python itself.
Comment 54 Ryan Hill (RETIRED) gentoo-dev 2005-09-17 23:47:49 UTC
(In reply to comment #50)
> (In reply to comment #49)
> > Everyone is saying that changing CHOST is just for "cosmetics." But when I've 
> > tried installing glibc with nptl it requires a minimum CHOST value and would 
> > not accept using i386. So unless the devs that support glibc just did that 
> > arbitrarily, there seems to be something more than "cosmetics."
> 
> It's arbitrary.  Changing CHOST has no effect other than changing the location
> of the toolchain files.

unfortunately it does have a big effect.  try this on an x86 machine.

- change CHOST in /etc/make.conf to i686-pc-linux-gnu.
- USE="nptl nptlonly -linuxthreads-tls" emerge -aDv glibc

>>> emerge (1 of 1) sys-libs/glibc-2.3.5.20050722 to /
>>> Unpacking source...

 * Checking gcc for __thread support ... yes
 * Checking kernel version (>=2.6.6) ... yes
 * Checking linux-headers version (>=2.6.6) ... yes
[snip]
 * Configuring GLIBC for nptl with:  --disable-nls --disable-dev-erandom
--enable-omitfp --with-tls --with-__thread --enable-add-ons=nptl,c_stubs,libidn
--enable-kernel=2.6.6 --without-selinux

- change CHOST in /etc/make.conf to i386-pc-linux-gnu.
- USE="nptl nptlonly -linuxthreads-tls" emerge -aDv glibc

>>> emerge (1 of 1) sys-libs/glibc-2.3.5.20050722 to /
>>> Unpacking source...
[snip]
 * Configuring GLIBC for linuxthreads with:  --disable-nls --disable-dev-erandom
--enable-omitfp --without-tls --without-__thread
--enable-add-ons=linuxthreads,c_stubs,libidn --enable-kernel=2.4.1 --without-selinux

that's hardly arbitrary.
Comment 55 Bryan Østergaard (RETIRED) gentoo-dev 2005-09-18 02:04:57 UTC
I didn't add dev-lang/python to DEPEND in python-fchksum for two reasons.

1. I'm slightly scared that might introduce a circular dependency.
2. It does nothing to solve the problem as python is already emerged and I
really need a way to force rebuilding of python before python-fchksum to solve
the problem completely.

The current PDEPEND in python solves the problem if only people followed the
handbook properly and remembered to emerge -e system after bootstrapping.

I don't think it's currently possible (or advisable) to support other paths when
changing CHOST. Too many other things can (and almost always) go wrong like
broken libc and gcc when arbitrarily changing CHOST.
Comment 56 Alexander Skwar 2005-09-18 02:40:19 UTC
(In reply to comment #41)

> No, it isn't.  Gentoo is about *empowering* the user to make choices.  We don't
> allow choice for the simple sake of choice, otherwise we would have a convoluted
> mass of nonworking junk.  Basically, if you're changing your CHOST settings,
> *AGAINST THE ADVICE OF THE DEVELOPERS*, which is nothing more than a *COSMETIC*
> change anyway, then you should be willing and knowledgeable enough to pick up
> the pieces when it vomits all over your system.

Wrong. People change CHOST, because the documentation says so. Since it is the
Gentoo documentation, it's the task of Gentoo to fix problems it created. Also,
in the Gentoo documentation, I cannot find any advice at all, that the CHOST
should NOT be changed. Actually, the opposite is true.

If you'd like people to not change CHOST, you should file a bug to change the
documentation.

>  Now, we're working to "fix"
> this "problem" for the people that *insist* on maintaining a broken behavior,

That the documentation suggests to make. Important difference!

Actually, upon closer reading the documentation, there's *VERY* strong
suggestion to MAKE THAT CHANGE.

> but it has nothing to do with "choice" or any lack thereof and more to do with
> protecting our users from themselves.
> 
> All of that being said, I modifed catalyst to use CHOST=i686-pc-linux-gnu by

What about i486 and i586 users?

Comment 57 Marius Mauch (RETIRED) gentoo-dev 2005-09-18 18:13:46 UTC
(In reply to comment #55)

> Wrong. People change CHOST, because the documentation says so. Since it is the
> Gentoo documentation, it's the task of Gentoo to fix problems it created. Also,
> in the Gentoo documentation, I cannot find any advice at all, that the CHOST
> should NOT be changed. Actually, the opposite is true.
> 
> If you'd like people to not change CHOST, you should file a bug to change the
> documentation.

Where do the docs say such a thing? The only reference to CHOST in the handbook
has a big fat warning at the top.
Comment 58 Chris Slycord 2005-09-18 19:04:06 UTC
(In reply to http://bugs.gentoo.org/show_bug.cgi?id=88777#c56 )
> Where do the docs say such a thing? The only reference to CHOST in the handbook
> has a big fat warning at the top.

1) The 2005.1 guide states "Users interested in bootstrapping their entire
system with NPTL support on an x86 system need to set their CHOST to
i586-pc-linux-gnu or higher."

2) The warning you mention clearly says that people who aren't doing stage1
installs should leave CHOST unchanged. This isn't saying "Don't change CHOST."

(Confirming http://bugs.gentoo.org/show_bug.cgi?id=88777#c53 )
When I had CHOST="i386-pc-linux-gnu" glibc was compiled with "--without-tls" and
when I changed CHOST back to "i386-pc-linux-gnu" emerging glibc compiled it with
"--with-tls".
Comment 59 Marius Mauch (RETIRED) gentoo-dev 2005-09-18 19:53:06 UTC
(In reply to comment #57)
> (In reply to http://bugs.gentoo.org/show_bug.cgi?id=88777#c56 )
> > Where do the docs say such a thing? The only reference to CHOST in the handbook
> > has a big fat warning at the top.
> 
> 1) The 2005.1 guide states "Users interested in bootstrapping their entire
> system with NPTL support on an x86 system need to set their CHOST to
> i586-pc-linux-gnu or higher."
> 
> 2) The warning you mention clearly says that people who aren't doing stage1
> installs should leave CHOST unchanged. This isn't saying "Don't change CHOST."

Both means you're doing a stage1 install following the handbook, and then
changing CHOST can work (and the fix mentioned here solves only that scenario).
And I still don't see any encouragement to change CHOST.
Disclaimer: I only read up comment #54 and following, and the top comments that
actually deal with this bug, so I missed all the unrelated stuff from Chris and
thought comment #55 was somehow related to comment #54. Seeing now that this is
not completely the case feel free to ignore my comments.

@Chris: if catalyst now defaults to i686 CHOST, is there any reason for catalyst
to set CHOST in make.conf at all? If not, maybe the best idea would be to remove
it from make.conf in the stages as it's already set in the profiles.
Comment 60 Rémi Cardona gentoo-dev 2005-09-18 21:22:09 UTC
Changing CHOST default to 686 means all users wanting to install gentoo on
pentiums, k6, first gen epias and a bunch of other cpus will have to change
their CHOST back to 586. That means the problem can still arise if people don't
follow the manual which clearly states that changing CHOST should be immediately
followed by an emerge -e world.

My understanding of the doc is that CHOST should only be changed during a stage1
install, and only if needed (nptl for instance). If it were such a terrible
thing to do, then the doc should be improved to reflect those views.

Now if this bug has been fixed but is still getting dupes (at least two or three
every week) maybe the doc should also be changed so that stage1 users don't
forget to run through emerge -e world. (I know it's written, I read it, but
maybe saying it differently or in Big Bright Red Block Letters will do the trick)

Maybe portage could be used to figure out if CHOST matches the one in, say,
bash. If CHOST and the CHOST used to compile bash are different, notify the user
that something fishy's going on and that he should run emerge -e world to have a
coherent system.
Comment 61 Alexander Skwar 2005-09-18 21:49:18 UTC
(In reply to comment #56)

> Where do the docs say such a thing? The only reference to CHOST in the handbook
> has a big fat warning at the top.

The docs at
http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#book_part1_chap5__chap5_sect2
say so. And there's no warning. The only warning that's there, is not relevant
for stage-1 users.
Comment 62 Alexander Skwar 2005-09-18 21:52:22 UTC
(In reply to comment #58)
> (In reply to comment #57)
> > (In reply to http://bugs.gentoo.org/show_bug.cgi?id=88777#c56 )
> > > Where do the docs say such a thing? The only reference to CHOST in the
handbook
> > > has a big fat warning at the top.
> > 
> > 1) The 2005.1 guide states "Users interested in bootstrapping their entire
> > system with NPTL support on an x86 system need to set their CHOST to
> > i586-pc-linux-gnu or higher."
> > 
> > 2) The warning you mention clearly says that people who aren't doing stage1
> > installs should leave CHOST unchanged. This isn't saying "Don't change CHOST."
> 
> Both means you're doing a stage1 install following the handbook, and then
> changing CHOST can work (and the fix mentioned here solves only that scenario).

No, changing CHOST does NOT work. When you do a stage1 install and set the
make.conf the way it's reqd. (which, according to the docs, includes changing
CHOST), the "emerge -e system" will stop at python-fchksum.

> And I still don't see any encouragement to change CHOST.

Well. Then please read the docs.

| Users interested in bootstrapping their entire system with NPTL support on an
x86 system need to set their CHOST to i586-pc-linux-gnu or higher.

Comment 63 Alexander Skwar 2005-09-18 22:01:36 UTC
(In reply to comment #59)
> Changing CHOST default to 686 means all users wanting to install gentoo on
> pentiums, k6, first gen epias and a bunch of other cpus will have to change
> their CHOST back to 586. That means the problem can still arise if people don't
> follow the manual which clearly states that changing CHOST should be immediately
> followed by an emerge -e world.

No, it doesn't say so. When doing a stage 1 install, make.conf and CHOST is
changed before anything else is done. It's changed *BEFORE* "emerge -e system".
And in THIS case, users will get stopped when pyhton-fchksum is to be compiled.

Or do you suggest to do "emerge -e world" *BEFORE* doing the very first, initial
"emerge -e system"?

If so, then that's not covered by the handbook at
http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1

> My understanding of the doc is that CHOST should only be changed during a stage1
> install, and only if needed (nptl for instance).

Well, the docs make it sound, as if it were a must to change CHOST when nptl is
used. In other cases, it sounds to me, as if the user is free to change the
setting at will (if done soon enough).

> If it were such a terrible
> thing to do, then the doc should be improved to reflect those views.

Yes, that's exactly right.

> Now if this bug has been fixed but is still getting dupes (at least two or three
> every week) maybe the doc should also be changed so that stage1 users don't
> forget to run through emerge -e world. (I know it's written, I read it, but

Where is it written? Reading the handbook, I cannot find anything wrt this.

Comment 64 Chris Gianelloni (RETIRED) gentoo-dev 2005-09-19 08:52:06 UTC
Is there a chance that we can quit this discussion on this bug?  I've already
posted Bug #105809 to have all of this resolved in the Handbook.

CHOST is *purely* cosmetic on x86.  The fact that the glibc ebuild uses it to
determine whether nptl can be used or not is a *bug* and not a good argument,
since it is *wrong* to do that kind of check.

As for the CHOST being i686-pc-linux-gnu by default, that *does not matter* for
i486/i586 users in any way, as it is *cosmetic* and does not change the output
of GCC in any way.  Only compiler settings via CFLAGS actually changes the
compiled output.  Let me say this again for those of you not paying much
attention and wanting to continue beating this dead horse.

ONLY COMPILER SETTINGS VIA CFLAGS ACTUALLY CHANGES THE COMPILED OUTPUT.

CHOST has no effect.
Comment 65 Chris Slycord 2005-09-19 15:48:29 UTC
Just as an update -
I bugged the fact that glibc compiles differently when only changing CHOST.

http://bugs.gentoo.org/show_bug.cgi?id=106556
Comment 66 Chris Slycord 2005-09-19 23:20:09 UTC
Can someone help? That bug I posted (where glibc is built differently based on
changing your CHOST value) was resolved as invalid by vapier. He said that the
behavior described is valid.

So it seems that changing CHOST isn't for "cosmetics" after all.
Comment 67 Christohper Harrington 2005-09-21 02:02:47 UTC
Spectacular, except I followed the instructions yesterday on running a stage-1,
exactly as the handbook stated, changing my CHOST for NPTL (because I can't get
it any other way), doing a bootstrap, and then doing emerge -e system. Guess what?

This bug is *NOT* resolved! I don't care about your personal opinions about
beating this to death; it's a bug, and following the instructions leaves the
user staring at an error with no idea how to continue. This bug should remain
*OPEN*, not closed, until the bug is fixed or the root cause (users NEED to
change CHOST) is eliminated. Fix glibc, then you can fix this.
Comment 68 SpanKY gentoo-dev 2005-09-21 22:31:09 UTC
*** Bug 89009 has been marked as a duplicate of this bug. ***
Comment 69 Chris Slycord 2005-09-21 22:45:10 UTC
Just to make something clear. Changing CHOST is actually needed for NPTL-support
as NPTL hasn't been ported to i386.

https://www.redhat.com/archives/fedora-devel-list/2004-June/msg00035.html

"i386 (and sparc < v9) lacks atomic instructions powerful enough for NPTL needs."
Comment 70 Mike Green 2005-09-22 13:42:52 UTC
This bug should not be closed.  It pretty much renders any custom install of
gentoo using NPTL pointless because it will fail every time.  I build all of my
boxes from stage1 with CHOST set to i686 because I require nptl.  Following the
instructions as-is to install from stage1 in the Gentoo Handbook, the emerge -e
system fails.  It has not always failed, cannot tell you when it started, but I
know the failure started somewhere between 2005-07-07 and 2005-08-26.

If you cannot follow the instructions in the Gentoo Handbook to achieve a stage1
install with NPTL, there is not much point to using gentoo.  This bug is
breaking the entire distrib and should be resolved before blaming users and glibc.
Comment 71 Chris Gianelloni (RETIRED) gentoo-dev 2005-09-22 14:22:51 UTC
You do know that there's a solution and we aren't going to bother reading any
more of this bug, right?  In fact, I know that I quit paying attention a long
time ago, specifically around comment #46 where I filed a bug for the
documentation resolution, along with making modifications to our release tools.

The truth is that I know what glibc does, and I still think it is incorrect, and
yes, I've read the bug report on glibc and how it acts, so don't bother going on
quoting it, I can read myself.  Basically, you guys are continuing to beat a
dead horse with absolutely no net gain, as this won't be able to be resolved
quickly as it requires a new Gentoo release to properly fix.

Again, if you're doing a stage1 installation, *especially* if you're doing NPTL,
then you're kinda on your own (and always have been).  I mean, have you thought
about trying to fix your system yourself?  After all, there's nowhere in the
Handbook describing doing a NPTL-based installation, you came up with that on
your own.  What makes you think that fixing a system that is breaking due to
your own actions isn't something that can be done yourself?  I know that I'm
probably not winning myself any friends or anything, but I'm honestly not
running for president.  We've said that this is resolved in portage, and it *is*
resolved if you have proper release media.  The 2005.1 release media is *not*
sufficient for this task.

Anyway, if you want a NPTL system, you should be doing a stage3 installation, as
I said before, and making the changes to your system, then doing an emerge -e
world.  This is the recommended path going forward and it is quite likely that
we will *only* be supporting this method in the future.  The stage1 release
media simply generates too many user-generated bugs that end up being the
developer's problem.
Comment 72 Rafael Ávila de Espíndola 2005-09-23 12:24:10 UTC
in case someone else hits the "dead horse":   
   
uncomment    
#inherit distutils    
in python-fchksum-1.7.1.ebuild    
    
works fine with a 2005.1 stage 1  
 
Comment 73 Chris Slycord 2005-09-23 15:36:33 UTC
(In reply to comment #70)
> After all, there's nowhere in the Handbook describing doing a NPTL-based 
> installation, you came up with that on your own.

As pointed out earlier, from:

http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1

"Users interested in bootstrapping their entire system with NPTL support on an 
x86 system need to set their CHOST to i586-pc-linux-gnu or higher."
Comment 74 Mike Green 2005-09-25 17:56:14 UTC
NPTL is a standard USE flag, building with it has worked for me for months now.
 Something has recently broken and it is not glibc or using NPTL.

I AM building from a stage1 -> stage3.  It is the emerge -e system after the
bootstrap that bombs.  I am following the Gentoo Handbook exactly and it does
not work.  I just tried it again and it is still broken.  Perhaps someone should
add to the handbook "if you are building a stage3, after the bootstrap.sh
re-emerge pythong before performing the emerge -e system".
Comment 75 Bryan Østergaard (RETIRED) gentoo-dev 2005-09-26 15:00:09 UTC
I just added dev-lang/python to the python-fchksum dependencies which fixes the
problem for now at least. Lets hope it doesn't cause circular dependencies down
the road..
Comment 76 Carsten Lohrke (RETIRED) gentoo-dev 2005-09-27 15:30:48 UTC
*** Bug 107457 has been marked as a duplicate of this bug. ***
Comment 77 Jakub Moc (RETIRED) gentoo-dev 2005-09-28 05:52:39 UTC
*** Bug 107496 has been marked as a duplicate of this bug. ***
Comment 78 Chris Gianelloni (RETIRED) gentoo-dev 2005-10-12 15:46:24 UTC
kloeri:  I've been building stages with catalyst using a snapshot with python in
the DEPEND of python-fchksum and it is still not working properly.  For some
reason, the depgraph is not pulling in python before python-fchksum.

I think that we should probably REOPEN this and try to figure out what's going
on here.
Comment 79 Henrik Brix Andersen 2005-10-14 00:55:20 UTC
FWIW, I just did a stage1 install with changed CHOST setting - and python was 
pulled in just before python-fchksum, solving the previous problem I had 
(comment #14).
Comment 80 Chris Gianelloni (RETIRED) gentoo-dev 2005-10-20 07:00:35 UTC
Re: comment #77

I had forgotten to also update python on the snapshot I was using.  Once I did
so, the problem went away.  Good job on getting this one resolved, kloeri!
Comment 81 Chris Gianelloni (RETIRED) gentoo-dev 2005-11-21 06:53:53 UTC
This is fixed with the 2005.1-r1 release media.
Comment 82 Pietro Franchi 2006-04-13 15:33:37 UTC
Hi, I've just installed a stable x86 chroot from a stage3 (2006.0).

Now, doing an emerge -e world, python-fchksum-1.7.1 get emerged before python, causing this very same bug to happen. 

I can reproduce and give any additional info, if needed.
Comment 83 Fredric Johansson 2006-05-14 09:46:41 UTC
I
Comment 84 Fredric Johansson 2006-05-14 09:46:41 UTC
I´ve been into this bug 2 times. once when I changed my CHOST on an installed system(thats my own fault) AND the second time when downloading the latest stage2-i686-tarball I found for a testing-environment. I didnt change CHOST just CFLAGS and USE. Can anybody explain why the problem still exists more than half a year later in an almost new stage2-tarball? Shouldnt python be compiled with a i686-gcc if this causes this problem?
Its easysolved if you know what the problem is and how to solve it but for other people it causes this "weird" problem.
Comment 85 Olliver Schinagl 2007-04-18 11:38:35 UTC
(In reply to comment #84)

I don't know if anybody even see's this bug anymore, but I just bumped into it myself. I used a stage3 x86 uclibc tarball that was I think quite recent, changed CHOST to i686, and I do belive emerge -e system and emerge -e world, both worked fine, but when installing python-checksum into my '/tinygentoo' dir it wanted to compile itself with the i386 gcc, which was of course long gone. remerging python in my buildsystem fixed it all, but it was still odd to say the least.

Comment 86 Rémi Cardona gentoo-dev 2007-04-18 17:23:27 UTC
That's because you're not supposed to change CHOST, see comment #42. Thanks