Created attachment 824861 [details] compressed build log emerge -pv x11-libs/cairo [ebuild R ] x11-libs/cairo-1.16.0-r6::gentoo USE="X glib opengl svg utils* (-aqua) -debug (-gles2-only) -static-libs -valgrind" ABI_X86="(64) -32 (-x32)" 0 KiB results in this error: /bin/sh ../../libtool --tag=CC --mode=link x86_64-pc-linux-gnu-gcc -D_REENTRANT -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/libpng16 -Wall -Wextra -Wmissing-declarations -Werror-implicit-function-declaration -Wpointer-arith -Wwrite-strings -Wsign-compare -Wpacked -Wswitch-enum -Wmissing-format-attribute -Wvolatile-register-var -Wstrict-aliasing=2 -Winit-self -Wunsafe-loop-optimizations -Wno-missing-field-initializers -Wno-unused-parameter -Wno-attributes -Wno-long-long -Winline -fno-strict-aliasing -fno-common -Wp,-D_FORTIFY_SOURCE=2 -Wno-unused-but-set-variable -D_REENTRANT -O2 -march=znver1 -pipe -module -no-undefined -avoid-version -Wl,-O1 -Wl,--as-needed -o libcairo-trace.la -rpath /usr/lib64/cairo libcairo_trace_la-trace.lo libcairo_trace_la-lookup-symbol.lo -lpthread -lz -ldl -lbfd -lrt -lm libtool: link: x86_64-pc-linux-gnu-gcc -shared -fPIC -DPIC .libs/libcairo_trace_la-trace.o .libs/libcairo_trace_la-lookup-symbol.o -Wl,-rpath -Wl,//usr/lib -Wl,--as-needed -lpthread //usr/lib/libbfd.so -L/var/tmp/portage/sys-devel/binutils-2.30-r4/work/binutils-2.30/bfd/../libiberty/pic -liberty -lz -ldl -lrt -lm -O2 -march=znver1 -Wl,-O1 -Wl,-soname -Wl,libcairo-trace.so -o .libs/libcairo-trace.so /usr/lib/gcc/x86_64-pc-linux-gnu/10.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: //usr/lib/libbfd.so: error adding symbols: file in wrong format collect2: error: ld returned 1 exit status make[4]: *** [Makefile:556: libcairo-trace.la] Error 1 full and compressed build log is attached
Created attachment 824863 [details] output from emerge --info
I don't know much about libtool, but this command seems to be a problem: libtool: link: x86_64-pc-linux-gnu-gcc -shared -fPIC -DPIC .libs/libcairo_trace_la-trace.o .libs/libcairo_trace_la-lookup-symbol.o -Wl,-rpath -Wl,//usr/lib -Wl,--as-needed -lpthread //usr/lib/libbfd.so -L/var/tmp/portage/sys-devel/binutils-2.30-r4/work/binutils-2.30/bfd/../libiberty/pic -liberty -lz -ldl -lrt -lm -O2 -march=znver1 -Wl,-O1 -Wl,-soname -Wl,libcairo-trace.so -o .libs/libcairo-trace.so why twice a slash before the dir, seemingly checking the 32bit libdir on a -abi_x86_32 build, and no idea why it seems to want to link through /var/tmp/portage/
Does this problem occur with x11-libs/cairo-1.17.6?
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #3) > Does this problem occur with x11-libs/cairo-1.17.6? no, it doesn't have the utils useflag anymore: > -Dgtk2-utils=disabled
My guess is that there is a pkgconfig file with invalid data installed on your system.
(In reply to Mike Gilbert from comment #5) > My guess is that there is a pkgconfig file with invalid data installed on > your system. might be, do you have any suspect one I can check?
It could also be a broken .la file. You might grep for '/usr/lib ' and '/usr/lib$' in /usr/lib64 and /usr/local/lib64. I can't really tell you exactly what to look for.
Check config.log etc. and Makefiles for /usr/lib references. (In reply to tt_1 from comment #4) > > Does this problem occur with x11-libs/cairo-1.17.6? > > no, it doesn't have the utils useflag anymore: > > > -Dgtk2-utils=disabled This is unrelated. In 1.16.0: $(use_enable utils trace) In 1.17.6, this functionality is enabled automagically: https://gitlab.freedesktop.org/cairo/cairo/-/blob/1.17.6/meson.build: > have_ld_preload = ['linux', 'freebsd', 'darwin', 'dragonfly'].contains(host_machine.system()) > > if have_ld_preload and zlib_dep.found() and conf.get('CAIRO_HAS_REAL_PTHREAD', 0) == 1 and conf.get('CAIRO_HAS_DLSYM', 0) == 1 > conf.set('CAIRO_HAS_TRACE', 1) > endif https://gitlab.freedesktop.org/cairo/cairo/-/blob/1.17.6/util/meson.build: > if conf.get('CAIRO_HAS_TRACE', 0) == 1 > subdir('cairo-trace')
Do you have stray libbfd.la or something (from sys-devel/binutils-2.30-r4 ???)?
in any case, =x11-libs/cairo-1.17.6 is unaffected. it seems libtool file has interesting ideas of lib dirs: cat /var/tmp/portage/x11-libs/cairo-1.16.0-r6/work/cairo-1.16.0-abi_x86_64.amd64/libtool | grep '/usr/lib' # Compile-time system search path for libraries. sys_lib_search_path_spec="/usr/lib/gcc/x86_64-pc-linux-gnu/10.4.0 /usr/lib64 /lib64 /usr/x86_64-pc-linux-gnu/lib /usr/lib /lib " but that shouldn't matter, as fare as I know, if it does find what its looking for in the first three places, right?
Created attachment 824867 [details] config.log only odd thing I see is this: > /usr/lib/gcc/x86_64-pc-linux-gnu/10.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lsocket: No such file or directory
The /usr/lib/libbfd.so would belong to sys-libs/binutils-libs but shouldn't that actually be lib32? as the directory name? Here it seems your system picks supposedly 32bit library and tries to link it with 64bit binary. Check using qfile to what package belongs this file, maybe you have it installed outside of Portage, and now you hit it.
(In reply to Piotr Karbowski from comment #12) > The /usr/lib/libbfd.so would belong to sys-libs/binutils-libs but shouldn't > that actually be lib32? as the directory name? Here it seems your system > picks supposedly 32bit library and tries to link it with 64bit binary. correct, /usr/lib/libbfd.so is a symlink to the 32bit lib file in the same folder ( libbfd-2.38.gentoo-sys-libs-binutils-libs-st-def.so ) - why it wants to link that on a pure abi_x86_64 build is beyond me. > Check using qfile to what package belongs this file, maybe you have it > installed outside of Portage, and now you hit it. no I haven't, its installed with binutils-libs someone in irc mentioned its a lookalike of https://bugs.gentoo.org/795315 ; I believe it was ionen
(In reply to Piotr Karbowski from comment #12) > The /usr/lib/libbfd.so would belong to sys-libs/binutils-libs but shouldn't > that actually be lib32? as the directory name? Here it seems your system > picks supposedly 32bit library and tries to link it with 64bit binary. > > Check using qfile to what package belongs this file, maybe you have it > installed outside of Portage, and now you hit it. lib32 was dropped in the 17.0->17.1 profile migration, we use 'lib' for 32-bit.
Run full grep if you have not done it already: grep -r /var/tmp/portage/sys-devel/binutils-2.30 /bin /sbin /lib* /usr
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #15) > Run full grep if you have not done it already: > grep -r /var/tmp/portage/sys-devel/binutils-2.30 /bin /sbin /lib* /usr ah lol, there it is: /usr/lib64/libbfd.la:dependency_libs=' -L/var/tmp/portage/sys-devel/binutils-2.30-r4/work/binutils-2.30/bfd/../libiberty/pic -liberty -lz -ldl' I really don't know how it got there, its certainly not owned by any package and I absolutly never ever compiled binutils on my own. Maybe it was not converted during the 17.0 to 17.1 profile switch?
I suggested the same possibility in comment #9...
Whatever the cause, it probably happened a while ago and we are unlikely to figure out the exact sequence of events.
