sys-libs/libstdc++-v3-3.3.6-r1 fails with "c-parse.y:614:16: error: 'YYLEX' undeclared (first use in this function)" build.log and emerge --info will be attached Reproducible: Always
Created attachment 376364 [details] build.log.xz
Created attachment 376366 [details] emerge --info
I also tried using sys-devel/gcc-4.7.3-r1 and it also failed. However, sys-libs/libstdc++-v3-3.3.6:5 fails with another error (using sys-devel/gcc-4.8.2): /var/tmp/portage/sys-libs/libstdc++-v3-3.3.6/work/gcc-3.3.6/gcc/unwind-dw2.c: In function `uw_frame_state_for': /var/tmp/portage/sys-libs/libstdc++-v3-3.3.6/work/gcc-3.3.6/gcc/unwind-dw2.c:954: error: field `info' has incomplete type
Created attachment 376458 [details, diff] gcc-3.3.6-gcc-no-yylex-macro.patch This patch might fix it correctly. At least it gets it compiling. The problem is this: https://savannah.gnu.org/forum/forum.php?forum_id=7663 Fixing the whole toolchain patchset for that is going to take some doing. See https://www.opengl.org/discussion_boards/showthread.php/183714-Cannot-build-glslang-on-Linux for an example... not sure I understand it myself. Hopefully, for libstdc++-v3 we lucked out: no YYLEX_PARAM is provided in the places that matter. Does gcc-3.3.6/gcc/intl/plural.c get built? If so, that might be a problem, as it is used there.
*** Bug 509890 has been marked as a duplicate of this bug. ***
The patch posted by Greg Turner solves the problem for me. Thanks! About the question of "gcc-3.3.6/gcc/intl/plural.c" beeing built: I don't find it mentioned in the build.log so I'd guess that it's not built.
I'm also affected by this bug, however the patch provided by Greg works and the package builds properly.
Confirming the bug, the path fixes it for me. The bug arises most probably only with the new sys-devel/bison-3. You should update the summary and add it to the tracker #510654.
(In reply to Greg Turner from comment #4) > Created attachment 376458 [details, diff] [details, diff] > gcc-3.3.6-gcc-no-yylex-macro.patch > > This patch might fix it correctly. At least it gets it compiling. > I had same problem and this patch works for me. Thnx.
+ 26 Jun 2014; Michał Górny <mgorny@gentoo.org> libstdc++-v3-3.3.6-r1.ebuild: + Filter out -frecord-gcc-switches. Require <bison-3 until the underlying issue + is fixed properly, bug #509572. Since I don't feel comfortable with bison, I've just updated the deps. I'd prefer if someone more aware of the implications would decide to apply the patch.
*** Bug 522920 has been marked as a duplicate of this bug. ***
no decision on this yet?
FWIW I just had to fight this exact thing. The gcc-3.3.6-gcc-no-yylex-macro.patch patch from Greg Turner worked perfectly. The 'DEPEND="<sys-devel/bison-3"' that was added as a workaround in libstdc++-v3-3.3.6-r1.ebuild wouldn't work for me, because I need libreoffice (whose dependencies now require >= bison 3) to coexist on the same box as the Adaptec RAID utility arcconf (which requires libstdc++-v3, which requires < bison 3). Note for anyone trying this at home - just dropping the patch in /etc/portage/patches/ won't work (even if epatch_user gets called - the ebuild doesn't do so explicitly but one of the classes it inherits might automatically; I didn't check, because): the existing DEPEND must be updated, or portage won't try to emerge this with bison 3 installed even though it'll work. N.B. I am not a bison expert either, and this patch might make a herd of wild bison trample your car next week.
Can you post an updated ebuild? I tried this patch but maybe I am applying it wrong here is the ebuild as I created it # Copyright 1999-2014 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: /var/cvsroot/gentoo-x86/sys-libs/libstdc++-v3/libstdc++-v3-3.3.6-r1.ebuild,v 1.13 2014/06/26 08:24:44 mgorny Exp $ inherit eutils flag-o-matic libtool multilib transform_known_flags() { declare setting # and on x86, we just need to filter the 3.4 specific amd64 -marchs replace-cpu-flags k8 athlon64 opteron x86-64 # gcc 3.3 doesn't support -march=pentium-m replace-cpu-flags pentium-m pentium3m pentium3 #GCC 3.3 does not understand G3, G4, G5 on ppc replace-cpu-flags G3 750 replace-cpu-flags G4 7400 replace-cpu-flags G5 7400 } is_arch_allowed() { i386_processor_table="i386 i486 i586 pentium pentium-mmx winchip-c6 \ winchip2 c3 i686 pentiumpro pentium2 pentium3 pentium4 prescott \ nocona k6 k6-2 k6-3 athlon athlon-tbird x86-64 athlon-4 athlon-xp \ athlon-mp" for proc in ${i386_processor_table} ; do [ "${proc}" == "${1}" ] && return 0 done mips_processor_table="mips1 mips2 mips3 mips4 mips32 mips64 r3000 r2000 \ r3900 r6000 r4000 vr4100 vr4111 vr4120 vr4300 r4400 r4600 orion \ r4650 r8000 vr5000 vr5400 vr5500 4kc 4kp 5kc 20kc sr71000 sb1" for proc in ${mips_processor_table} ; do [ "${proc}" == "${1}" ] && return 0 done rs6000_processor_table="common power power2 power3 power4 powerpc \ powerpc64 rios rios1 rsc rsc1 rios2 rs64a 401 403 405 505 601 602 \ 603 603e ec603e 604 604e 620 630 740 750 7400 7450 8540 801 821 823 \ 860" for proc in ${rs6000_processor_table} ; do [ "${proc}" == "${1}" ] && return 0 done return 1 } do_filter_flags() { declare setting # In general gcc does not like optimization, and add -O2 where # it is safe. This is especially true for gcc 3.3 + 3.4 replace-flags -O? -O2 # gcc 3.3 doesn't support -mtune on numerous archs, so xgcc will fail setting="`get-flag mtune`" [ ! -z "${setting}" ] && filter-flags -mtune="${setting}" # in gcc 3.3 there is a bug on ppc64 where if -mcpu is used # the compiler incorrectly assumes the code you are about to build # is 32 bit use ppc64 && setting="`get-flag mcpu`" [ ! -z "${setting}" ] && filter-flags -mcpu="${setting}" # only allow the flags that we -know- are supported transform_known_flags setting="`get-flag march`" if [ ! -z "${setting}" ] ; then is_arch_allowed "${setting}" || filter-flags -march="${setting}" fi setting="`get-flag mcpu`" if [ ! -z "${setting}" ] ; then is_arch_allowed "${setting}" || filter-flags -mcpu="${setting}" fi # xgcc wont understand gcc 3.4 flags... filter-flags -fno-unit-at-a-time filter-flags -funit-at-a-time filter-flags -fweb filter-flags -fno-web filter-flags -mno-tls-direct-seg-refs # xgcc isnt patched with propolice filter-flags -fstack-protector-all filter-flags -fno-stack-protector-all filter-flags -fstack-protector filter-flags -fno-stack-protector # xgcc isnt patched with the gcc symbol visibility patch filter-flags -fvisibility-inlines-hidden filter-flags -fvisibility=hidden # Bug #269433 & #290202 filter-flags -fno-strict-overflow filter-flags -fstrict-overflow # Bug #442784 filter-flags '-W*' filter-flags -frecord-gcc-switches # ...sure, why not? strip-unsupported-flags strip-flags } PATCH_VER="1.8" DESCRIPTION="Compatibility package for running binaries linked against a pre gcc 3.4 libstdc++" HOMEPAGE="http://gcc.gnu.org/libstdc++/" SRC_URI="ftp://gcc.gnu.org/pub/gcc/releases/gcc-${PV}/gcc-${PV}.tar.bz2 mirror://gentoo/gcc-${PV}-patches-${PATCH_VER}.tar.bz2" LICENSE="GPL-2 LGPL-2.1" SLOT="5" KEYWORDS="amd64 ~mips ppc -ppc64 sparc x86 ~x86-fbsd" IUSE="multilib nls" DEPEND="sys-devel/bison" RDEPEND="" S=${WORKDIR}/gcc-${PV} src_unpack() { unpack ${A} cd "${S}" EPATCH_SUFFIX="patch" epatch "${WORKDIR}"/patch elibtoolize --portage --shallow ./contrib/gcc_update --touch mkdir -p "${WORKDIR}"/build if use multilib && [[ ${SYMLINK_LIB} == "yes" ]] ; then # ugh, this shit has to match the way we've hacked gcc else # the build falls apart #259215 sed -i \ -e 's:\(MULTILIB_OSDIRNAMES = \).*:\1../lib64 ../lib32:' \ "${S}"/gcc/config/i386/t-linux64 \ || die "sed failed!" fi } src_prepare() { epatch "${FILESDIR}"/gcc-3.3.6-gcc-no-yylex-macro.patch } src_compile() { cd "${WORKDIR}"/build do_filter_flags ECONF_SOURCE=${S} \ econf \ --enable-shared \ --with-system-zlib \ --enable-languages=c++ \ --enable-threads=posix \ --enable-long-long \ --disable-checking \ --enable-cstdio=stdio \ --enable-__cxa_atexit \ $(use_enable multilib) \ $(use_enable nls) \ $(use_with !nls included-gettext) touch "${S}"/gcc/c-gperf.h emake all-target-libstdc++-v3 || die } src_install() { emake -j1 \ -C "${WORKDIR}"/build \ DESTDIR="${D}" \ install-target-libstdc++-v3 || die # scrub everything but the library we care about pushd "${D}" >/dev/null mv usr/lib* . || die rm -rf usr rm -f lib*/*.{a,la,so} || die dodir /usr mv lib* usr/ || die }
and here is the error emerging var/tmp/portage/sys-libs/libstdc++-v3-3.3.6-r2/work/gcc-3.3.6/gcc/cpplib.h:487:17: warning: type of bit-field ‘type’ is a GCC extension [-Wpedantic] ENUM_BITFIELD(node_type) type : 8; /* CPP node type. */ ^ /var/tmp/portage/sys-libs/libstdc++-v3-3.3.6-r2/work/gcc-3.3.6/gcc/system.h:509:34: note: in definition of macro ‘ENUM_BITFIELD’ #define ENUM_BITFIELD(TYPE) enum TYPE ^ /var/tmp/portage/sys-libs/libstdc++-v3-3.3.6-r2/work/gcc-3.3.6/gcc/gcc.c:6022:4: warning: ‘fd’ may be used uninitialized in this function [-Wmaybe-uninitialized] close (fd); ^ make[1]: Leaving directory '/var/tmp/portage/sys-libs/libstdc++-v3-3.3.6-r2/work/build/gcc' Makefile:1546: recipe for target 'all-gcc' failed make: *** [all-gcc] Error 2 emake failed * ERROR: sys-libs/libstdc++-v3-3.3.6-r2::miscellaneous failed (compile phase): * (no error message) * * Call stack: * ebuild.sh, line 93: Called src_compile * environment, line 2719: Called die * The specific snippet of code: * emake all-target-libstdc++-v3 || die
I have the sam issue as ut2004 requires this package yet bison 3 is required for many other things on my box
queued in the patchset http://sources.gentoo.org/gentoo/src/patchsets/gcc/3.3.6/gentoo/10_all_gcc-3.4.6-c-parse-bison-3.patch?rev=1.1 it'll be released via bug 519704
should be all set now in the tree; thanks for the report! Commit message: Fix building with newer bison-3 http://sources.gentoo.org/sys-libs/libstdc++-v3/libstdc++-v3-3.3.6-r1.ebuild?r1=1.13&r2=1.14