checking for nl_langinfo and CODESET... yes
checking for LC_MESSAGES... yes
checking whether NLS is requested... yes
checking whether included gettext is requested... no
checking for libintl.h... yes
checking for GNU gettext in libc... yes
checking for dcgettext... yes
checking for msgfmt... /usr/bin/msgfmt
checking for gmsgfmt... /usr/bin/gmsgfmt
checking for xgettext... /usr/bin/xgettext
checking for bison... bison
checking version of bison... 2.6.5, ok
checking for catalogs to be installed... be ca da de el es fr ja nl rw sv tr be ca da de el es fr ja nl rw sv tr
checking what assembler to use... /usr/x86_64-pc-linux-gnu/bin/as
checking what linker to use... /usr/x86_64-pc-linux-gnu/bin/ld
checking what nm to use... nm
checking what objdump to use... objdump
checking assembler alignment features... .p2align including maximum skip
checking assembler subsection support... working .subsection -1
checking assembler weak support... yes
checking assembler hidden support... yes
checking assembler leb128 support... /var/tmp/portage/sys-libs/libstdc++-v3-3.3.6-r1/work/gcc-3.3.6/gcc/configure: 7352: test: GNU: unexpected operator
checking assembler eh_frame optimization... yes
checking assembler section merging support... yes
checking assembler thread-local storage support... yes
checking assembler instructions... filds fists
checking cmov syntax... no
checking assembler GOTOFF in data directives... no
checking assembler dwarf2 debug_line support... yes
checking assembler --gdwarf2 support... yes
checking assembler --gstabs support... yes
checking linker read-only and read-write section mixing... read-write
checking linker PT_GNU_EH_FRAME support... yes
checking linker --as-needed support... yes
The following requested languages were not found: c++
The following languages were available: c
Configure in /var/tmp/portage/sys-libs/libstdc++-v3-3.3.6-r1/work/build/gcc failed, exiting.
* ERROR: sys-libs/libstdc++-v3-3.3.6-r1 failed (compile phase):
* econf failed
Reproduced on two machines, the failure mode is the same and goes away if /bin/sh is bash again.
Portage 220.127.116.11 (default/linux/amd64/10.0, gcc-4.6.3, glibc-2.16.0, 3.5.4-vs18.104.22.168 x86_64)
System uname: Linux-3.5.4-vs22.214.171.124-x86_64-AMD_Phenom-tm-_II_X4_965_Processor-with-gentoo-2.2
Timestamp of tree: Unknown
ld GNU ld (GNU Binutils) 2.23.1
dev-lang/python: 2.7.3-r2, 3.2.3-r1
sys-kernel/linux-headers: 3.6 (virtual/os-headers)
CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt /usr/share/themes/oxygen-gtk/gtk-2.0"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
FEATURES="assume-digests binpkg-logs buildpkg config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch protect-owned sandbox sfperms strict test unknown-features-warn unmerge-logs unmerge-orphans userfetch"
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"
USE="acl amd64 berkdb bzip2 cli cracklib crypt cups cxx dri egl fortran gdbm gpm iconv ipv6 mmx modules mudflap multilib ncurses nls nptl openmp openvg pam pcre pppd readline session sqlite sse sse2 ssl tcpd unicode xa xvfb zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" PHP_TARGETS="php5-3" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_2" RUBY_TARGETS="ruby19" USERLAND="GNU" VIDEO_CARDS="vesa" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
Created attachment 478546 [details, diff]
The offending test is intrinsically broken because it assumes that the version number is to be found immediately after an opening bracket. Here are some sample strings that show this assumption to be erroneous:
Arch: GNU assembler (GNU Binutils) 126.96.36.19970506
Ubuntu Xenial: GNU assembler (GNU Binutils for Ubuntu) 2.26.1
Gentoo: GNU assembler (Gentoo 2.28 p1.2) 2.28
The attached patch does away with this nasty code and, instead, employs the following behaviour:
1) Uses parameter expansion to get the version number i.e. the final word from the line
2) Captures the major and minor fields by way of a simple read statement that splits on .
Sorry, I should have said that the existing code assumes that the version number is to be found immediately after the text, "GNU assembler ", rather than an opening bracket. The supplied patch still stands.
Does it still happen? If it does for you please attach full build.log.
The leb128 test is still intrinsically broken:
checking assembler leb128 support...
./configure: 7352: test: GNU: unexpected operator
Effectively, it is doing this:
$ dash -c 'test GNU assembler \(Gentoo 2 -eq 2 -a 30 -lt 11'
dash: 1: test: GNU: unexpected operator
In my testing, the only difference now is that the erroneous test command doesn't cause the configure phase to take exception, with it carrying on regardless. Brittle, to say the least.
As before, the provided patch stops any erroneous shell code from attempting to be executed and has the test function as intended.
Please attach full build.log. I can't reproduce build failure locally and would like to check the difference.
$ LANG=C ls -l /bin/sh
lrwxrwxrwx 1 root root 4 Feb 16 22:05 /bin/sh -> dash
I cannot. I didn't say that it was still failing. On the contrary:
"In my testing, the only difference now is that the erroneous test command doesn't cause the configure phase to take exception, with it carrying on regardless."
In summary, the overall build failed when I tested it in 2017 but not when I tested it at the time of my last comment. There's no use in attaching a build log because a) I cannot now reproduce a build failure b) it doesn't provide any insight into the syntactically invalid shell code that is still composed and conveyed to the shell during one of the tests.
Regarding (b), I have explained the original issue thoroughly and supplied a patch that remains valid and applicable. There's really not much more that I can say. While the outcome of the test is not important for Gentoo - having, as it does, a modern binutils - it is still a broken test that has previously resulted in build failures. Maybe it will again. I don't use this package so I won't be investigating any further.
If proof is still needed, try running:-
# ebuild libstdc++-v3-3.3.6-r1.ebuild compile 2>&1 | perl -ne 'print if /leb128 support/../eh_frame/'
(In reply to Kerin Millar from comment #6)
> I cannot. I didn't say that it was still failing
Aha. Then it's not an instance of the original bug reported here. That was probably fixed with a patchset bump in bug #665768
> Regarding (b), I have explained the original issue thoroughly and supplied a
> patch that remains valid and applicable
I believe that was fixed upstream as:
I'd rather not backport it as long as it does not cause any issues.
Closing as OBSOLETE.
(In reply to Sergei Trofimovich from comment #8)
> I believe that was fixed upstream as:
> I'd rather not backport it as long as it does not cause any issues.
I see. Yes, the present build deduces that leb128 support is available anyway, so I suppose it matters not at this point.