Summary: | build of coreutils-5.2.1-r7 hangs | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Perttu Luukko <perttu.luukko> |
Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | High | ||
Version: | 2005.1 | ||
Hardware: | x86 | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=133489 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Perttu Luukko
2006-01-28 02:26:10 UTC
what version of texinfo do you have ? Thanks for the reply. I have sys-apps/texinfo-4.8-r2 -- the latest stable. I already tried re-emerging it but it had no effect. A have same error at amd64. test.c:129: error: static declaration of 'eaccess' follows non-static declaration /usr/include/gentoo-multilib/amd64/unistd.h:266: error: previous declaration of 'eaccess' was here if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I. -I../lib -I../lib -O9 -march=k8 -fomit-frame-pointer -falign-functions=32 -falign-labels=32 -falign-loops=32 -falign-jumps=32 -mfpmath=sse -msse2 -m3dnow -pipe -s -MT chown-core.o -MD -MP -MF ".deps/chown-core.Tpo" -c -o chown-core.o chown-core.c; \ then mv -f ".deps/chown-core.Tpo" ".deps/chown-core.Po"; else rm -f ".deps/chown-core.Tpo"; exit 1; fi make[3]: *** [lbracket.o] Error 1 make[3]: *** Waiting for unfinished jobs.... make[3]: Leaving directory `/var/tmp/portage/coreutils-5.2.1-r7/work/coreutils-5.2.1/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/var/tmp/portage/coreutils-5.2.1-r7/work/coreutils-5.2.1/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/coreutils-5.2.1-r7/work/coreutils-5.2.1' make: *** [all] Ошибка 2 > A have same error at amd64. what are you talking about ? your error looks *nothing* like what is posted here > test.c:129: error: static declaration of 'eaccess' follows non-static > declaration uhh, dont use masked gcc versions with stable packages, it just aint gonna work I can't see either how #3 is related... The problem persists, and the same thing seems to happen with coreutils-5.3.0-r2. Now that everything below 5.2.1-r7 has gone from portage, I'll have to find the old r6 ebuild and put it in an overlay, or try something in the 5.94-range - I'm just not quite sure I am adventurous enough :) If someone has any ideas I'm all ears. 5.94-r1 is stable now so you can give that a spin Thanks, SpanKY -- 5.94-r1 seems to work like a charm. Since the latest stable fixes the problem (whatever it was, I have no idea), let's leave this as FIXED. Feel free to reopen if it comes back to haunt someone. In case someone is still interested, I got to the bottom of this bug: setting TIME_STYLE breaks older versions of automake, causing the mdate-sh script to go on a infinite loop because ls now outputs something unexpected (see http://lists.nongnu.org/archive/html/bug-findutils/2005-06/msg00160.html). I bumped again to this bug when libtool suddenly refused to rebuild - doing a 'unset TIME_STYLE' before emerging fixes this. The bug in mdate-sh should be fixed in the 1.9 branch of automake and later. I probably should file a separate bug for this, as packages requiring older versions of automake still fail is TIME_STYLE is set. another good example of autopatching autotool files ... |