Created attachment 586116 [details] build.log (plain cflags) I've been unable to build bind-tools 9.14.4. I was previously on bind-tools-9.12.3_p4 without issue, and have since encountering this error upgraded to the unstable unkeyworded 9.15.2 without issue. The brief version of the error: /usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libpthread.a when searching for -lpthread /usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc /usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libc.a when searching for -lc /usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: i386 architecture of input file `/var/tmp/portage/net-dns/bind-tools-9.14.4/temp/crc64_test.YEOHWk.ltrans0.ltrans.o' is incompatible with i386:x86-64 output collect2: error: ld returned 1 exit status make[2]: *** [Makefile:475: crc64_test] Error 1 and this error repeats for several of the blah_test jobs as make stops due to these errors. This (and the attached build log) was done with the following plain c and cxxflags -march=native -O2 -pipe (when lto is involved the error message is unclear due to the lto-plugin or something crashing at around the same point)
Created attachment 586118 [details] emerge --info
Created attachment 586120 [details] environment
Created attachment 586122 [details] build.log (lto)
The bug here is in LTO compiler SIGSEGV: lto1: internal compiler error: Segmentation fault 0x7fe823d0c48f ??? /var/tmp/portage/sys-libs/glibc-2.29-r3/work/glibc-2.29/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0 0x7fe823cf6f1a __libc_start_main ../csu/libc-start.c:308 0xcf65c9 ??? ../sysdeps/x86_64/start.S:120 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://bugs.gentoo.org/> for instructions. Probably caused by use of explicit path to 32-bit libs: '-L/usr/lib' x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -flto -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu -DDIG_SIGCHASE -pthread -I/usr/include/libxml2 -fPIC \ -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu -march=native -O2 -pipe -flto -Wl,--export-dynamic -o hash_test hash_test.o \ ../libisc.a -L/usr/lib -lcrypto -lxml2 -lz -llzma -licui18n -licuuc -licudata -lm -ldl -lcmocka /usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libcrypto.so when searching for -lcrypto
Yeah.. the bug/issue is why isn't it finding /usr/lib64. It's not picking it up for whatever reason with or without lto. What is this version doing wrong that the old version, and the dev version were doing right? I havn't ran into any issues building anything else, and am rebuilding everything bind-tools depends on (emerge -e)
(In reply to Sergei Trofimovich from comment #4) > Probably caused by use of explicit path to 32-bit libs: '-L/usr/lib' This particular issue is caused by an outdated macro ax_check_openssl.m4, which tries "crypto" pkgconfig file instead of "libcrypto" or "openssl" and fallbacks to hardcoded libdir. This was fixed in bind-tools-9.15*.
Is this after an incomplete profile update related to bug #506276?
(In reply to Jeroen Roovers from comment #7) > Is this after an incomplete profile update related to bug #506276? (Not quite.)
I redefined ldflags with proper libdir, should be fine now.
