I'm trying to get a pure uclibc++ system. And while emptying the tree again, I notice bison has got some issues. Reproducible: Always Steps to Reproduce: emerge bison Actual Results: g++ -DHAVE_CONFIG_H -I. -I. -I../.. -march=i586 -Os -fomit-frame-pointer -pipe -c -o calc++-scanner.o calc++-scanner.cc ../../build-aux/depcomp: line 512: exec: g++: not found make[4]: *** [calc++-scanner.o] Error 127 make[4]: Leaving directory `/var/tmp/portage/bison-2.1/work/bison-2.1/examples/calc++' make[3]: *** [all] Error 2 make[3]: Leaving directory `/var/tmp/portage/bison-2.1/work/bison-2.1/examples/calc++' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/tmp/portage/bison-2.1/work/bison-2.1/examples' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/bison-2.1/work/bison-2.1' make: *** [all] Error 2 Expected Results: I think it should be trivial to add a nocxx flag to bison. wartepiet usr # emerge info Portage 2.0.53_rc7 (uclibc/x86/2005.1, gcc-3.4.4, uclibc-0.9.27-r0, 2.6.14-gentoo-r1 x86_64) ================================================================= System uname: 2.6.14-gentoo-r1 x86_64 AMD Athlon(tm) 64 Processor 3500+ Gentoo Base System version 1.12.0_pre11 dev-lang/python: 2.3.4-r1, 2.4.2 sys-apps/sandbox: 1.2.14 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.20-r1 virtual/os-headers: 2.6.11-r3 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i586-gentoo-linux-uclibc" CFLAGS="-march=i586 -Os -fomit-frame-pointer -pipe" CHOST="i586-gentoo-linux-uclibc" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=i586 -Os -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks nodoc noinfo noman sandbox sfperms strict" GENTOO_MIRRORS="ftp://192.168.1.2/ http://distfiles.gentoo.org/" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 bitmap-fonts bzip2 expat mmx ncurses nocxx readline truetype-fonts type1-fonts uclibc udev zlib userland_GNU kernel_linux elibc_uclibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS
(In reply to comment #0) > I'm trying to get a pure uclibc++ system. And while emptying the tree again, I > notice bison has got some issues. The funny thing with the nocxx use flag is that it causes gcc to be built without support for C++. Hence, the g++ executable cannot be found, and apparently bison's build needs that. Fortunately there is a solution to this problem: to rebuild the entire system with the nocxx use flag removed.
From /usr/portage/profiles/use.desc: nocxx - Disable support for C++ (DONT USE THIS UNLESS YOU KNOW WHAT YOU'RE DOING)
Created attachment 73913 [details, diff] No examples patch for Makefile.in (In reply to comment #1) > The funny thing with the nocxx use flag is that it causes gcc to be built > without support for C++. Hence, the g++ executable cannot be found, and > apparently bison's build needs that. Fortunately there is a solution to this > problem: to rebuild the entire system with the nocxx use flag removed. There is, by preventing the calc++ EXAMPLE to be build. I do exactly know what I'm doing and it is plain simple: if bison only uses g++ to build one stupid example just disable it. By useflags minimal or nocxx. The last one should imply the first. if use minimal; then einfo "Disable the examples for users who know what they are doing" epatch ${FILESDIR}/noexamples.diff fi
As stated in the last reply, not invalid for *this* particular ebuild.
hmm, cant we just not build the examples that require C++ support ? seems like we should be able to figure out if CXX support exists or not since the configure script checks for it ...
There is only one example ;) But I tryed to remove the subdirs from the Makefile in the examples directory, I'm not a hero with Makefile voodoo, because it then complains about not able to make 'all'. This 'patch' could work ok, for minimal, but if you want to support nocxx the calc++ subdir should not be compiled.
When building a release, stage1 is built without C++ support. We do not use the "nocxx" USE flag, however. Anyway, it has been reported that this breaks building stages, which means it will block 2006.1's release.
Does anyone know if this is still an issue?
Well, it didn't block the release. As such, I think it's safe for us to be removed.
(In reply to comment #9) > Well, it didn't block the release. As such, I think it's safe for us to be > removed. As in close the issue, or remove the examples with a useflag?
i think bison-2.4 should work OK w/out C++
