With texinfo 5.1 gcc fails to build. Reproducible: Always Steps to Reproduce: 1. emerge -1 =sys-apps/texinfo-5.1 2. emerge -1 =sys-devel/gcc-4.7.2-r1 3. enjoy Actual Results: http://bpaste.net/show/87987/ if [ -n "(Gentoo 4.7.2-r1 p1.5, pie-0.5.5) " ]; then \ echo "@set VERSION_PACKAGE (Gentoo 4.7.2-r1 p1.5, pie-0.5.5) " >> gcc-vers.texiT; \ fi echo "@set BUGURL @uref{http://bugs.gentoo.org/}" >> gcc-vers.texiT; \ mv -f gcc-vers.texiT gcc-vers.texi if [ xinfo = xinfo ]; then \ makeinfo --split-size=5000000 --split-size=5000000 --split-size=5000000 --no-split -I . -I /var/tmp/portage/sys-devel/gcc-4.7.2-r1/work/gcc-4.7.2/gcc/doc \ -I /var/tmp/portage/sys-devel/gcc-4.7.2-r1/work/gcc-4.7.2/gcc/doc/include -o doc/cpp.info /var/tmp/portage/sys-devel/gcc-4.7.2-r1/work/gcc-4.7.2/gcc/doc/cpp.texi; \ fi /var/tmp/portage/sys-devel/gcc-4.7.2-r1/work/gcc-4.7.2/gcc/doc/cppopts.texi:806: @itemx must follow @item make[3]: *** [doc/cpp.info] Error 1 make[3]: Leaving directory `/var/tmp/portage/sys-devel/gcc-4.7.2-r1/work/build/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/var/tmp/portage/sys-devel/gcc-4.7.2-r1/work/build' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/var/tmp/portage/sys-devel/gcc-4.7.2-r1/work/build' make: *** [bootstrap-lean] Error 2 emake failed With texinfo-4.13-r2 all works fine.
Created attachment 343848 [details] emerge --info
Created attachment 343850 [details] emerge --info from the right machine
Created attachment 343852 [details] failed gcc-4.7.2-r1 build.log Sorry, i didn't think about availability of pastebins. Hope this is better.
I'm able to reproduce this issue.
Hello everyone, I want to give you small notice this issue not only related with gcc I came across when emerging automake. I think this bug *probably* related with "texinfo 5.1" also texinfo-4.13-r2 works like a charm :-)
we'll probably have to hack the build system to not regen info pages at all
this seems to have fixed it for me: http://sources.gentoo.org/eclass/toolchain.eclass?r1=1.571&r2=1.572
(In reply to comment #5) > Hello everyone, > > I want to give you small notice this issue not only related with gcc I came > across when emerging automake. I think this bug *probably* related with > "texinfo 5.1" also texinfo-4.13-r2 works like a charm :-) For me it happens with texinfo-4.13-r2 and also with the updated eclass.
After upgrade to sys-apps/texinfo-5.1 I cannot recompile gcc package and automake. I downgraded texinfo to 4.13-r2 it helps to compile automake again, but gcc is still failing to compile.
Created attachment 343980 [details] /var/tmp/portage/sys-devel/gcc-4.7.2-r1/temp/build.log
Created attachment 343982 [details] emerge --info
(In reply to comment #7) > this seems to have fixed it for me: > http://sources.gentoo.org/eclass/toolchain.eclass?r1=1.571&r2=1.572 Now I get: if [ xinfo = xinfo ]; then \ makeinfo --split-size=5000000 --split-size=5000000 --split-size=5000000 --no-split -I . -I /var/tmp/portage/sys-devel/gcc-4.8.0/work/gcc-4.8.0/gcc/doc \ -I /var/tmp/portage/sys-devel/gcc-4.8.0/work/gcc-4.8.0/gcc/doc/include -o doc/cpp.info /var/tmp/portage/sys-devel/gcc-4.8.0/work/gcc-4.8.0/gcc/doc/cpp.texi; \ fi /var/tmp/portage/sys-devel/gcc-4.8.0/work/gcc-4.8.0/gcc/doc/include/gcc-common.texi:11: @include `gcc-vers.texi': No such file or directory. makeinfo: Removing output file `doc/cpp.info' due to errors; use --force to preserve. make[3]: *** [doc/cpp.info] Error 1
*** Bug 464138 has been marked as a duplicate of this bug. ***
FWIW, I get the same as others, on ~amd64. Neither the updated eclass nor masking texinfo 5.1 allowed gcc:4.6 or gcc:4.7 to (re)build. The only thing that has worked, is using emerge-webrsync to pull a portage snapshot from a few days ago (20130329, to be exact--before texinfo 5.1 and before the eclass changes), after which emerging gcc:4.7 and gcc:4.6 succeed again.
Or just delete that line from toolchain.eclass. I reverted the change since enough people are hitting it.
*** Bug 464166 has been marked as a duplicate of this bug. ***
(In reply to comment #7) > this seems to have fixed it for me: > http://sources.gentoo.org/eclass/toolchain.eclass?r1=1.571&r2=1.572 how about: sed -i 's/BUILD_INFO=info/BUILD_INFO=/' gcc/configure
Ryal Hill, is your change already in portage? gcc-4.7.2 still fails for me. Do I need to do anything special?
His change is in portage but you should still expect gcc to fail when built with texinfo-5.1. It should now build ok with texinfo-4* though.
Not to drive the slaves :) But with the certificate fixed I'd like to reference my dup bug. 464166 build.log , I was able to pull out alot of .texi references with line numbers. I was also seeing these in glibc-2.17, but it compiled complete and I wasn't going to file a bug. I'm not a hacker and it's not my place to offer a patch for gcc. Hope it helps.
*** Bug 464324 has been marked as a duplicate of this bug. ***
(In reply to comment #19) > His change is in portage but you should still expect gcc to fail when built > with texinfo-5.1. It should now build ok with texinfo-4* though. So to clarify... 1) If one built gcc with texinfo-5.1, rebuilding gcc will not work and building future versions apparently won't work either. 2) Working around this issue for those who built it with texinfo-5.1 requires finding a binary package of a version built without texinfo-5.1 and then uninstalling the one built texinfo-5.1.
Oops. I meant that to be a question...
You can just downgrade texinfo to 4.x and gcc builds will work again. This is only a build-time dep (and failure), so the problem only affects (re)building gcc, it does not break your already-installed gcc.
(In reply to comment #17) > (In reply to comment #7) > > this seems to have fixed it for me: > > http://sources.gentoo.org/eclass/toolchain.eclass?r1=1.571&r2=1.572 > > how about: > sed -i 's/BUILD_INFO=info/BUILD_INFO=/' gcc/configure That looks reasonable to me.
(In reply to comment #17) not much point going to that. better to hit the source. http://sources.gentoo.org/eclass/toolchain.eclass?r1=1.574&r2=1.575
*** Bug 464836 has been marked as a duplicate of this bug. ***
Now most info files aren't getting installed at all. --- replaced obj /usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0/info/libitm.info.bz2 --- replaced obj /usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0/info/libgomp.info.bz2 <<< obj /usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0/info/gccint.info.bz2 <<< obj /usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0/info/gccinstall.info.bz2 <<< obj /usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0/info/gcc.info.bz2 <<< obj /usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0/info/cppinternals.info.bz2 <<< obj /usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0/info/cpp.info.bz2 --- replaced dir /usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0/info Do we care?
(In reply to comment #28) that wasn't the intention. looks like the build system only installs info pages from the build tree and ignores the source tree altogether. this should fix that: http://sources.gentoo.org/eclass/toolchain.eclass?r1=1.575&r2=1.576
(In reply to comment #29) This fix fails, if there are no info files. I ran into this problem while crosscompiling for avr. Maybe the ebuild should not die, if there is no info file, because failing of the cp command isn't a fatal error.
Since the current "fix" seems to make build impossible I'm not sure this should be closed * ERROR: sys-devel/gcc-4.6.3 failed (install phase): * (no error message) * * Call stack: * ebuild.sh, line 93: Called src_install * environment, line 4247: Called toolchain_src_install * environment, line 4911: Called die * The specific snippet of code: * cp "${S}"/gcc/doc/*.info gcc/doc/ || die;
(In reply to comment #30) (In reply to comment #31) this makes no sense. gcc has long shipped with info files in that source dir (going back to at least 3.0). my guess is that you don't have a gcc/doc/ in the build output.
http://sources.gentoo.org/eclass/toolchain.eclass?r1=1.577&r2=1.578
I'm still getting the exact same failure on a fresh catalyst stage1 build. Is there something I'm missing?
Fails on my catalyst stage1 build. Fails on my main build box (outside of catalyst). Fails on my laptop (but that takes much longer). Gcc 4.6.3 stable is completely unbuildable for me right now.
(In reply to comment #35) so do the obvious triage. all you've said is "it fails". post a log. check your $S. check your $WORKDIR. verify you're actually using the latest version of sources that i committed. you're a dev ... i shouldn't need to explain each of these things.
Created attachment 344774 [details] build.log.xz I've attached my build log showing the same symptoms, but this is not an isolated issue. gcc builds are broken everywhere, as far as I can tell. Please either revert your toolchain.eclass changes, or provide a proper fix which you have tested locally with success. I'm current, too: # head -n3 /var/db/portage/eclass/toolchain.eclass # Copyright 1999-2013 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: /var/cvsroot/gentoo-x86/eclass/toolchain.eclass,v 1.578 2013/04/07 18:27:18 vapier Exp $
(In reply to comment #36) > (In reply to comment #35) > > so do the obvious triage. all you've said is "it fails". post a log. > check your $S. check your $WORKDIR. verify you're actually using the > latest version of sources that i committed. you're a dev ... i shouldn't > need to explain each of these things. I'm sorry, are you really unable to scroll up? Comment 31 contains the entirety of the error. Additionally if you are going to get an attitude perhaps I'll follow that tack as well... do you even test these changes you commit? you are randomly changing toolchain.eclass without any discussion or testing, you break gcc build, and then you blame me? If it is broken on three computers it's obviously not a stale work directory. I waited a full 60 minutes after your last change to sync, but just for fun I've run sync again, rebuilt, and I'm attaching the build.log.xz for you so you can scroll through a few megs of useless successful build messages and get to the very simple error I posted earlier today. Now that we have established that it's broken, any chance of a fix?
Created attachment 344776 [details] build.log.xz Build.log.xz from main build system inside of catalyst. toolchain.class: # $Header: /var/cvsroot/gentoo-x86/eclass/toolchain.eclass,v 1.578 2013/04/07 18:27:18 vapier Exp $
Created attachment 344778 [details] Ozzie build.log.xz Build log from my laptop toolchain.eclass # $Header: /var/cvsroot/gentoo-x86/eclass/toolchain.eclass,v 1.578 2013/04/07 18:27:18 vapier Exp $
Created attachment 344780 [details] Nu host Build log from my main build system outside of catalyst this time toolchain.eclass # $Header: /var/cvsroot/gentoo-x86/eclass/toolchain.eclass,v 1.578 2013/04/07 18:27:18 vapier Exp $
Created attachment 344782 [details] Build log Fresh install, stable esystem, emerge -e @world resulted in the same problem. $ emerge --info Portage 2.1.11.55 (default/linux/amd64/13.0/no-multilib, gcc-4.6.3, glibc-2.15-r3, 3.7.10-gentoo x86_64) ================================================================= System uname: Linux-3.7.10-gentoo-x86_64-Intel-R-_Xeon-R-_CPU_L5420_@_2.50GHz-with-gentoo-2.1 KiB Mem: 16441528 total, 13066284 free KiB Swap: 2097148 total, 2097148 free Timestamp of tree: Sun, 07 Apr 2013 18:45:01 +0000 ld GNU ld (GNU Binutils) 2.22 app-shells/bash: 4.2_p37 dev-lang/python: 3.2.3-r2 dev-util/pkgconfig: 0.28 sys-apps/baselayout: 2.1-r1 sys-apps/openrc: 0.11.8 sys-apps/sandbox: 2.5 sys-devel/autoconf: 2.69 sys-devel/automake: 1.10.3, 1.11.6, 1.12.6 sys-devel/binutils: 2.22-r1 sys-devel/gcc: 4.6.3 sys-devel/gcc-config: 1.7.3 sys-devel/libtool: 2.4-r1 sys-devel/make: 3.82-r4 sys-kernel/linux-headers: 3.7 (virtual/os-headers) sys-libs/glibc: 2.15-r3 Repositories: gentoo ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=core2 -mno-movbe -mno-aes -mno-pclmul -mno-popcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-tbm -mno-avx -mno-sse4.2 -msse4.1 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=6144 -mtune=core2 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/gentoo-release /etc/sandbox.d /etc/terminfo" CXXFLAGS="-march=core2 -mno-movbe -mno-aes -mno-pclmul -mno-popcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-tbm -mno-avx -mno-sse4.2 -msse4.1 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=6144 -mtune=core2 -O2 -pipe" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--jobs=4 --load-average 8 --keep-going --with-bdeps=y" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="en_US.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--sort-common -Wl,--hash-style=gnu" MAKEOPTS="-j8 --load-average=8" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://192.168.3.254/gentoo-portage" USE="acl amd64 berkdb bindist bzip2 caps cli cracklib crypt cxx fortran gdbm ipv6 ithreads lvm mdadm mmx modules mudflap ncurses nptl openmp pam pcre readline session sse sse2 ssl unicode vim-syntax xattr zlib" ABI_X86="64" ELIBC="glibc" GRUB_PLATFORMS="pc" INPUT_DEVICES="evdev keyboard" KERNEL="linux" LINGUAS="en en_US" PHP_TARGETS="php5-3" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_2" QEMU_SOFTMMU_TARGETS="i386 x86_64" QEMU_USER_TARGETS="i386 x86_64" RUBY_TARGETS="ruby18 ruby19" USERLAND="GNU" Unset: CPPFLAGS, CTARGET, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
>>> Install gcc-4.7.2-r1 into /var/tmp/portage/sys-devel/gcc-4.7.2-r1/image/ category sys-devel cp: cannot stat ‘/var/tmp/portage/sys-devel/gcc-4.7.2-r1/work/build/gcc/doc/*.info*’: No such file or directory * ERROR: sys-devel/gcc-4.7.2-r1 failed (install phase): * (no error message) # ls /var/tmp/portage/sys-devel/gcc-4.7.2-r1/work/build/gcc/doc/ g++.1 gcc.1 gfortran.1 gpl.7
Ah, it can't work anyway - /var/tmp/portage/sys-devel/gcc-4.7.2-r1/work/gcc-4.7.2/gcc/doc/ only contains manpages and texi files, no info. So there's nothing to copy ...
This makes info page installation work: - cp "${S}"/gcc/doc/*.info* gcc/doc/ || die + cp "${WORKDIR}/${P}"/gcc/doc/*.info* gcc/doc/ || die Committed as toolchain.eclass revision 1.579
(In reply to comment #45) > This makes info page installation work: > > - cp "${S}"/gcc/doc/*.info* gcc/doc/ || die > + cp "${WORKDIR}/${P}"/gcc/doc/*.info* gcc/doc/ || die > > Committed as toolchain.eclass revision 1.579 This fixes it for me, my stable systems are stable once again. Thanks!
*** Bug 465024 has been marked as a duplicate of this bug. ***
(In reply to comment #38) no, your comment #31 doesn't include an actual error message. if you can't snip a log properly, then don't snip it at all. post the whole thing. comment #43 includes the *actual* error. (In reply to comment #45) that's a hack. reverted and fixed the underlying bug. http://sources.gentoo.org/eclass/toolchain.eclass?r1=1.579&r2=1.580
*** Bug 465076 has been marked as a duplicate of this bug. ***
(In reply to comment #48) > no, your comment #31 doesn't include an actual error message. if you can't > snip a log properly, then don't snip it at all. post the whole thing. I'm a little impressed that after not one but two OBVIOUSLY completely untested commits you still have the stones to attack me for not snipping logs up to your oh so high standards.... Don't worry though, you only broke gcc build for stable and ~arch users for a day, no big deal, the fact that I'm unable to cut and paste logs correctly means it must be my fault it wasn't tested before commit, or tested after report, or tested on second "fix" of first untested "fix". sigh.
*** Bug 465118 has been marked as a duplicate of this bug. ***
(In reply to comment #50) you're clearly reading way more into comments. i never said these errors were your fault. i did say your logs were useless, and that devs should know how to read logs and be able to copy & paste a proper snippet. all of these things are true.
*** Bug 465294 has been marked as a duplicate of this bug. ***
As of the sync last night, this compiled cleanly for me. (my info is in bug 465024). Thanks!
*** Bug 252836 has been marked as a duplicate of this bug. ***
I might be going out on a limb here, I'm am an amateur, a alittle eccentric, and couldn't offer any usable code...BUT I am farming for math... And I was told by someone unnameable, that these .texi warnings are undocumented functions produced by cooking Gentoo. Instead of using sed to make them dissappear, at the risk of black hats getting mad, with this being far beyond myself. Shouldn't the objective be to document these and send this *Gentoo* only math upstream for proper patching? I'm far into the science overlay and I'm getting alot more when I get .texi warnings output. If we sed these away they are gone...for good. The distro already lost so much deep inside when gcc and glibc went C++. #Hope I'm not being redundant or out of line.
(In reply to Jason Mours from comment #56) i really have no idea what you're trying to say. we don't add custom math functionality to gcc or glibc.
(In reply to SpanKY from comment #57) > (In reply to Jason Mours from comment #56) > > i really have no idea what you're trying to say. we don't add custom math > functionality to gcc or glibc. No... I'm sorry, I was looking at gentoo from another perspective. And not to turn this bug into a forum, I will try and explain as best I can. I am currently -march=native & -Os. These are optimizations that prune functions throughout compile starting with glibc and gcc, these GNU programs compile themselves with themselves and generational compiles produce superior results. This is the fundamental to the C89 & C99 programming language. I also use python built -ggdb global. This builds functional heuristics and cleans code as it compiled. The heuristics are cumliative. Why? Not only is it inherrited behavior, but I also build with scikits-learning. This adds magic & machine learning to further utilizes learned compile over time. If glibc / gcc are constantly recompiled over time they soak in functions from adjectent programs & libraries as it compiles. Just watching gcc as it cites all the header files from the system for compile illustrated what I'm talking about. Even grub offers up functions for glibc & gcc to learn how the system boots. Now lets looks at C++, the spacial dimension that hackers exploit for performance, was producing entropy... perhaps usable entropy.... and I feel bad for gentoo's darwin. I mean underneath all that code that several optimizers have peeled layer after layer, generation after genration over the past decade? inside the machine (linear programming? BLAS? MLTON!!!) buried treasures have been paved over for a parking lot and are ..well..ruined. Portage is ruined now too... Python3 does not 'Learn', and will not untill 3.6 while python2 does. And when all that metadata got sliced and hacked, effectively his brain was lobotomized. And all that was learned from the past is lost. Smallest footprint in the opensource rsync, and everyone needed to prune... Oh well , my 2 cents. .texi warnings are undocumented functions that the library has soaked up. If someone could do some old fashion reverse engineering or look at a working box producing the warnings. Math could get pulled upstream. I even heard, and don't quote me... that GNU was started from reverse engineering soviet C, which was stolen from bell labs... lol.
This issue is referenced by the following in toolchain.eclass: # Disable gcc info regeneration -- it ships with generated info pages # already. Our custom version/urls/etc... trigger it. bug #464008 export gcc_cv_prog_makeinfo_modern=no This breaks with gcc-11. I have to comment out the export line to get info pages installed.
(In reply to Bernd Schmidt from comment #59) > This issue is referenced by the following in toolchain.eclass: > > # Disable gcc info regeneration -- it ships with generated info pages > # already. Our custom version/urls/etc... trigger it. bug #464008 > export gcc_cv_prog_makeinfo_modern=no > > This breaks with gcc-11. I have to comment out the export line to get info > pages installed. Please do not comment on closed bugs as it's extremely easy to miss. Your issue is something else, I'm fairly sure. It's almost certainly that GCC snapshots don't include generated info pages. It's not strictly related to this bug. Let's discuss this in bug 834845. Please over there include your emerge --info which will include the *full* GCC version (which matters).
