Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 509572 - sys-libs/libstdc++-v3-3.3.6-r1 with >sys-devel/bison-3 - c-parse.y:614:16: error: 'YYLEX' undeclared (first use in this function)
Summary: sys-libs/libstdc++-v3-3.3.6-r1 with >sys-devel/bison-3 - c-parse.y:614:16: er...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Toolchain Maintainers
URL:
Whiteboard:
Keywords:
: 509890 522920 (view as bug list)
Depends on:
Blocks: bison-3-breakage
  Show dependency tree
 
Reported: 2014-05-04 19:34 UTC by jannis
Modified: 2015-04-06 18:16 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
build.log.xz (build.log.xz,58.57 KB, application/x-xz)
2014-05-04 19:36 UTC, jannis
Details
emerge --info (einfo,25.12 KB, text/plain)
2014-05-04 19:36 UTC, jannis
Details
gcc-3.3.6-gcc-no-yylex-macro.patch (gcc-3.3.6-gcc-no-yylex-macro.patch,714 bytes, patch)
2014-05-06 03:30 UTC, Greg Turner
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description jannis 2014-05-04 19:34:37 UTC
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
Comment 1 jannis 2014-05-04 19:36:35 UTC
Created attachment 376364 [details]
build.log.xz
Comment 2 jannis 2014-05-04 19:36:53 UTC
Created attachment 376366 [details]
emerge --info
Comment 3 jannis 2014-05-04 19:41:32 UTC
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
Comment 4 Greg Turner 2014-05-06 03:30:20 UTC
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.
Comment 5 Jeroen Roovers (RETIRED) gentoo-dev 2014-05-09 04:41:08 UTC
*** Bug 509890 has been marked as a duplicate of this bug. ***
Comment 6 jannis 2014-05-10 06:51:28 UTC
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.
Comment 7 Victor Orozco 2014-05-21 07:46:44 UTC
I'm also affected by this bug, however the patch provided by Greg works and the package builds properly.
Comment 8 Petr Zima 2014-05-27 08:23:59 UTC
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.
Comment 9 daemonpnz 2014-06-13 16:45:11 UTC
(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.
Comment 10 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-06-26 08:25:32 UTC
+  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.
Comment 11 Jeroen Roovers (RETIRED) gentoo-dev 2014-09-16 06:10:14 UTC
*** Bug 522920 has been marked as a duplicate of this bug. ***
Comment 12 DJ Dunn 2015-02-19 18:51:02 UTC
no decision on this yet?
Comment 13 Hank Leininger 2015-02-24 04:09:48 UTC
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.
Comment 14 Billy DeVincentis 2015-02-24 12:46:54 UTC
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
}
Comment 15 Billy DeVincentis 2015-02-24 12:48:21 UTC
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
Comment 16 Billy DeVincentis 2015-02-24 12:50:05 UTC
I have the sam issue as ut2004 requires this package yet bison 3 is required for many other things on my box
Comment 18 SpanKY gentoo-dev 2015-04-06 18:16:38 UTC
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