Created attachment 466880 [details] emerge --info x86_64-pc-linux-gnu-gcc -DHAVE_LIBSSL -DNDEBUG -O2 -march=native -fno-stack-protector -U_FORTIFY_SOURCE -Wl,-O1 -Wl,--as-needed -o wget connect.o convert.o cookies.o ftp.o css_.o css-url.o ftp-basic.o ftp-ls.o hash.o host.o hsts.o html-parse.o html-url.o http.o init.o log.o main.o netrc.o progress.o ptimer.o recur.o res.o retr.o spider.o url.o warc.o xattr.o utils.o exits.o build_info.o iri.o version.o ftp-opie.o openssl.o ../lib/libgnu.a -lpcre -lidn2 -lssl -lcrypto -lz iri.o: In function `idn_encode': iri.c:(.text+0x51f): undefined reference to `uninorm_nfkc' collect2: error: ld returned 1 exit status make[3]: *** [Makefile:1565: wget] Error 1 make[3]: Leaving directory '/var/tmp/portage/net-misc/wget-1.19.1-r1/work/wget-1.19.1/src' make[2]: *** [Makefile:1464: all] Error 2 make[2]: Leaving directory '/var/tmp/portage/net-misc/wget-1.19.1-r1/work/wget-1.19.1/src' make[1]: *** [Makefile:1454: all-recursive] Error 1 make[1]: Leaving directory '/var/tmp/portage/net-misc/wget-1.19.1-r1/work/wget-1.19.1' make: *** [Makefile:1410: all] Error 2 * ERROR: net-misc/wget-1.19.1-r1::gentoo failed (compile phase): * emake failed * * If you need support, post the output of `emerge --info '=net-misc/wget-1.19.1-r1::gentoo'`, * the complete build log and the output of `emerge -pqv '=net-misc/wget-1.19.1-r1::gentoo'`. * The complete build log is located at '/var/tmp/portage/net-misc/wget-1.19.1-r1/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/net-misc/wget-1.19.1-r1/temp/environment'. * Working directory: '/var/tmp/portage/net-misc/wget-1.19.1-r1/work/wget-1.19.1' * S: '/var/tmp/portage/net-misc/wget-1.19.1-r1/work/wget-1.19.1'
Created attachment 466882 [details] build.log
Just got the same build error
Same :/ Portage 2.3.3 (python 3.4.5-final-0, default/linux/amd64/13.0, gcc-5.4.0, glibc-2.23-r3, 4.9.6-gentoo-r1 x86_64) ================================================================= System uname: Linux-4.9.6-gentoo-r1-x86_64-AMD_G-T40E_Processor-with-gentoo-2.3 KiB Mem: 4015560 total, 347340 free KiB Swap: 4162644 total, 4087068 free Timestamp of repository gentoo: Mon, 13 Mar 2017 18:30:01 +0000 sh bash 4.3_p48-r1 ld GNU ld (Gentoo 2.27 p1.0) 2.27 app-shells/bash: 4.3_p48-r1::gentoo dev-lang/perl: 5.22.3_rc4::gentoo dev-lang/python: 2.7.12::gentoo, 3.4.5::gentoo dev-util/cmake: 3.7.2::gentoo dev-util/pkgconfig: 0.28-r2::gentoo sys-apps/baselayout: 2.3::gentoo sys-apps/openrc: 0.23.2::gentoo sys-apps/sandbox: 2.10-r3::gentoo sys-devel/autoconf: 2.69::gentoo sys-devel/automake: 1.14.1::gentoo, 1.15::gentoo sys-devel/binutils: 2.27::gentoo sys-devel/gcc: 5.4.0-r3::gentoo sys-devel/gcc-config: 1.7.3::gentoo sys-devel/libtool: 2.4.6-r3::gentoo sys-devel/make: 4.2.1::gentoo sys-kernel/linux-headers: 4.4::gentoo (virtual/os-headers) sys-libs/glibc: 2.23-r3::gentoo Repositories: gentoo location: /opt/portage sync-type: rsync sync-uri: rsync://rsync.gentoo.org/gentoo-portage priority: -1 local location: /opt/local/portage masters: gentoo priority: 1 ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=native -pipe -fomit-frame-pointer -flto=3 -fuse-linker-plugin -fno-fat-lto-objects -floop-interchange -ftree-loop-distribution -floop-strip-mine -floop-block -ftree-vectorize -fopenmp" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt /var/bind /var/spool/munin-async/.ssh" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php7.0/ext-active/ /etc/php/cgi-php7.0/ext-active/ /etc/php/cli-php7.0/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -march=native -pipe -fomit-frame-pointer -flto=3 -fuse-linker-plugin -fno-fat-lto-objects -floop-interchange -ftree-loop-distribution -floop-strip-mine -floop-block -ftree-vectorize -fopenmp" DISTDIR="/opt/distfiles" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/ http://trumpetti.atm.tut.fi/gentoo/" LANG="en_US.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed -O2 -march=native -pipe -fomit-frame-pointer -flto=3 -fuse-linker-plugin -fno-fat-lto-objects -floop-interchange -ftree-loop-distribution -floop-strip-mine -floop-block -ftree-vectorize -fopenmp" MAKEOPTS="-j3" PKGDIR="/opt/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git" PORTAGE_TMPDIR="/var/tmp" USE="amd64 apache2 bcmath berkdb bzip2 caps cli cracklib crypt curl cxx dovecot-sasl dri exif fortran gd geoip gnutls graphite iconv idn imap ipv6 lto mdbox modules multilib mysql mysqli ncurses nls nptl openmp pam pcre readline sasl session sieve snmp sockets ssl syslog tcpd truetype udev unicode usb xattr xml zip zlib" ABI_X86="64" APACHE2_MODULES="authn_dbd authz_dbd dbd actions alias auth_basic authn_alias authn_anon authn_core authn_dbm authn_file authz_core authz_dbm authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir env expires ext_filter file_cache filter headers include info log_config logio mime mime_magic negotiation rewrite setenvif socache_shmcb speling status unique_id unixd userdir usertrack vhost_alias" CPU_FLAGS_X86="mmx mmxext popcnt sse sse2 sse3 sse4a ssse3" ELIBC="glibc" GPSD_PROTOCOLS="garmin" INPUT_DEVICES="libinput keyboard mouse" KERNEL="linux" PHP_TARGETS="php7-0" PYTHON_SINGLE_TARGET="python3_4" PYTHON_TARGETS="python3_4" RUBY_TARGETS="ruby21" USERLAND="GNU" Unset: CC, CPPFLAGS, CTARGET, CXX, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
It builds fine with =net-dns/libidn2-0.16-r1
i can't reproduce this. builds for me w/libidn2-0.11 & 0.16. the wget iri.c code has: #if IDN2_VERSION_NUMBER >= 0x00140000 ... #else ... use UNINORM_NFKC ... #endif UNINORM_NFKC itself comes from uninorm.h which is installed by libunistring. iri.c doesn't include it directly (it probably should), but includes unicase.h which includes uninorm.h which defines UNINORM_NFKC. that said, we don't depend on libunistring in the ebuild. do you guys have it installed ? looks like older libidn2 didn't depend on it either, so maybe 0.16 works purely because it also pulls in libunistring.
I ran into this link failure myself this morning; note that I had libidn 1.33 installed, and it hasn't been touched in at least a month. I did not have libunistring installed during the initial emerges where wget was failing to build, but if I emerge it, then the wget 1.19.1-r1 emerge succeeds: * Searching for libidn ... [IP-] [ ] net-dns/libidn-1.33:0 * Searching for libunistring ... [IP-] [ ] dev-libs/libunistring-0.9.7:0/2 * Searching for wget ... [IP-] [ ] net-misc/wget-1.19.1-r1:0 Let me know if I can provide any other useful info.
(In reply to SpanKY from comment #5) > > that said, we don't depend on libunistring in the ebuild. do you guys have > it installed ? looks like older libidn2 didn't depend on it either, so > maybe 0.16 works purely because it also pulls in libunistring. I reproduce this linking failure and I do not have libunistring installed. I am mostly on stable with =net-dns/libidn2-0.11. And I see that more recent versions of libidn2 ideed pull in libunistring.
(In reply to J. Paul Reed from comment #6) > * Searching for libidn ... > [IP-] [ ] net-dns/libidn-1.33:0 Oops... I just noticed libidn2 != libidn: I had libidn2-0.11 installed: * Searching for libidn2 ... [IP-] [ ] net-dns/libidn2-0.11:0
hmm, and it gets even better. it would appear that wget uses libunistring directly for older versions, but lets libidn2 do the encoding work with newer versions. so we need a dep like: || ( >=net-dns/libidn2-0.14 ( <net-dns/libidn2-0.14 dev-libs/libunistring ) ) but man is that ugly. would be a lot nicer to stabilize newer libidn2 and just have wget assume that everywhere. let me set up the bug dep tree to make that happen.
Same issue. I've net-dns/libidn-1.33 and net-dns/libidn2-0.11 installed and no installed dev-libs/libunistring.
(In reply to SpanKY from comment #9) > hmm, and it gets even better. it would appear that wget uses libunistring > directly for older versions, but lets libidn2 do the encoding work with > newer versions. so we need a dep like: > > || ( > >=net-dns/libidn2-0.14 > ( <net-dns/libidn2-0.14 dev-libs/libunistring ) > ) > > but man is that ugly. would be a lot nicer to stabilize newer libidn2 and > just have wget assume that everywhere. let me set up the bug dep tree to > make that happen. Actually, installing net-dns/libidn2-0.16-r1 pulls in dev-libs/libunistring. Thus is might be sufficient to just let wget depend on dev-libs/libunistring directly?
*** Bug 612604 has been marked as a duplicate of this bug. ***
same error here
(In reply to Marius Brehler from comment #11) net-dns/libidn2-0.16 isn't stable yet so we can't add it to the dep list. and if you have that version, then the libunistring dep is irrelevant as wget won't use it w/newer libidn2. basically we're waiting for bug 612376 to be fixed.
*** Bug 612646 has been marked as a duplicate of this bug. ***
Same issue. Pls fix this asap.
(In reply to cilly from comment #16) > Same issue. Pls fix this asap. As stated in comment #14, this is waiting for bug 612376 to be fixed. If this isn't clear enough already, I'll state that updating net-dns/libidn2 to version 0.16 before emerging wget is a workaround.
(In reply to Jaak Ristioja from comment #17) > As stated in comment #14, this is waiting for bug 612376 to be fixed. You mean this wget version should not have been marked as stable then. Now everybody's emerge -uavD world is borked due to this fallout. I suggest to withdraw this version from stable until it actually builds.
Same problem here. Please fix, this breaks emerge @world.
(In reply to Ortwin Glueck from comment #18) > (In reply to Jaak Ristioja from comment #17) > > As stated in comment #14, this is waiting for bug 612376 to be fixed. > > You mean this wget version should not have been marked as stable then. Now > everybody's emerge -uavD world is borked due to this fallout. I suggest to > withdraw this version from stable until it actually builds. Like that's a first... Without keywording net-dns/libidn2 you can still unbreak wget locally: https://wiki.gentoo.org/wiki/Knowledge_Base:Masking_a_package : "Sometimes it is good for Portage to not take into account a certain package or a specific version of a package. Reasons for such actions could be because the new version fails to work or drops a functionality, etc."
> Like that's a first... Without keywording net-dns/libidn2 you can still > unbreak wget locally: Look, wget isn't some obscure package. It's installed literally on *every* Gentoo out there. Man, this breaks everybody's world updates! EVERYBODY's! Are you seriously suggesting everybody modify their local config just that their daily updates still work? Please simply admit that a mistake has happened and pull this stabilization before this issue attracts more 'me too' posts. Can't be that hard.
(In reply to Ortwin Glueck from comment #21) > > Like that's a first... Without keywording net-dns/libidn2 you can still > > unbreak wget locally: > > Look, wget isn't some obscure package. It's installed literally on *every* > Gentoo out there. Man, this breaks everybody's world updates! EVERYBODY's! > Are you seriously suggesting everybody modify their local config just that > their daily updates still work? Please simply admit that a mistake has > happened and pull this stabilization before this issue attracts more 'me > too' posts. Can't be that hard. The developers are well aware of this issue, and I guess they have their valid reasons for the delay. I offered very simple workarounds to the problem until they fix this properly. Personally, I just wanted to reduce the "panic! me 2, plz fix fast!" spam in my inbox, but I guess I can also live without the notification of this getting fixed and will un-CC myself from this issue. Have fun! :)
please refrain from posting useless comments -- you're just adding noise. if you want to indicate your support for this bug, then use the "votes" field. then again, as other people have already stated, we're waiting on a different bug to be fixed before this one can be. so chiming in here doesn't make much sense. while wget might be on most people's systems (it certainly is not "literally on everyone's system"), USE=idn is not enabled by default anywhere. which means most people are not seeing this breakage.
One who introduced that broken ebuild should be removed from maintainers. It breaks everyones systems. It is unbelievable some maintainer can break @world and this state remains for more than 3 days already. Gentoo needs some serious quality assurance.
(In reply to Tomek L from comment #24) your comments are not helpful, nor your position reasonable. the goal is not to assign blame but to solve problems. please refrain from posting further here as it's not accomplishing anything. if you want to discuss larger issues, then use a proper forum like gentoo-dev@.
since libidn2-0.16 is stable now, i've forced that dep in the wget ebuild https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=59406355478a687004c5527c2e1b0dc532ebff3f
Unfortunately, the wget version was not bumped, which means that people who had masked =net-misc/wget-1.1.9.1-r1 (or useflagged it to -idn) won't get a new working one with an update. If they happen to come here and see that it has been fixed, they can of course manually remove their mask (or use flag) and force emerge it again, but that's not a given. Can wget be bumped to -r2?
(In reply to Arth from comment #27) sorry, but that isn't standard Gentoo policy. fail-to-build bugs don't usually get revbumps because you couldn't have merged them in the first place, thus the rule "revbump when set of installed files changes" doesn't apply. i don't see a good reason to change that for this.
