On Thu, Dec 28, 2006 at 01:00:00AM +0000, Duncan wrote: > > I don't have it merged here, but your net search apparently didn't include > a Gentoo bug search. Note that google (and presumably other websearch > engines) doesn't know how to index bugzilla pages very well, so you have > to search them separately.
You are right, I didn't search the gentoo bugs, but I shall in the future. I didn't know that Google wouldn't grab them... > Anyway, a quick search from http://bugs.gentoo.org on "ALL tclx", then > skipping to the bottom of the list since the bugs are in numerical order > and we are interested in something fairly new, yields a number of dups of > this bug: > > http://bugs.gentoo.org/show_bug.cgi?id=133099 > > It doesn't say what I was looking for directly, but it mentions related > emacspeak bug > > http://bugs.gentoo.org/show_bug.cgi?id=148854 > > which mentions (as you suspected) that the problem is a gcc-4.1 > incompatibility. There's tclx-8.4-r1 in the tree as ~amd64 and already > x86 stable, which compiles with gcc-4.1. However, certain packages that > depend on tclx apparently don't have a stable version in portage that can > handle tclx-8.4, so all those packages pretty much need to stabilize > together, and if one or more of them have other amd64 issues... > > So, bottom line, tclx-8.4-r1 is currently keyworded ~amd64. It works with > gcc-4.1, but since some stable versions of packages that depend on tclx > aren't 8.4 compatible, be prepared to package.keyword any of them too, in > ordered to get them working again after upgrading tclx. > > Or simply wait until everything is stabilized, staying with your gcc-3.4 > built version until then. The choice is yours. =8^) Excellent information. Thanks to all who answered my plea! -- -M There are 10 kinds of people in this world: Those who can count in binary and those who cannot. -- [email protected] mailing list
