After following instructions from 2019-06-05-amd64-17-1-profiles-are-now-stable I stuck at step 11. Initial the problem was with dev-util/cmocka : [2/3] : && /usr/bin/x86_64-pc-linux-gnu-gcc -fPIC -O2 -march=native -pipe -ftree-vectorize -flto -fuse-linker-plugin -mfpmath=sse -Wl,-O1 -Wl,--sort-common -flto -fuse-linker-plugin -shared -Wl,-soname,libcmocka.so.0 -o src/libcmocka.so.0.7.0 src/CMakeFiles/cmocka.dir/cmocka.c.o /usr/lib/librt.so && : FAILED: src/libcmocka.so.0.7.0 : && /usr/bin/x86_64-pc-linux-gnu-gcc -fPIC -O2 -march=native -pipe -ftree-vectorize -flto -fuse-linker-plugin -mfpmath=sse -Wl,-O1 -Wl,--sort-common -flto -fuse-linker-plugin -shared -Wl,-soname,libcmocka.so.0 -o src/libcmocka.so.0.7.0 src/CMakeFiles/cmocka.dir/cmocka.c.o /usr/lib/librt.so && : /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/librt.so: error adding symbols: file in wrong format collect2: error: ld returned 1 exit status It's clear this happens because used librt is 32bits instead of /usr/lib64/librt.so tachi / # file -L /usr/lib64/librt.so /usr/lib64/librt.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, for GNU/Linux 3.2.0, stripped tachi / # file -L /usr/lib/librt.so /usr/lib/librt.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, for GNU/Linux 3.2.0, stripped tachi / # Just to be sure I rebuilt bintuils and glibc once again, then tried to rebuild cmake (just in case). And with cmake I got very similar story: [ 83%] Linking CXX executable ../bin/cmake cd /tmp/portage/dev-util/cmake-3.18.4/work/cmake-3.18.4_build/Source && /usr/bin/cmake -E cmake_link_script CMakeFiles/cmake.dir/link.txt --verbose=1 /usr/bin/x86_64-pc-linux-gnu-g++ -O2 -march=native -pipe -ftree-vectorize -flto -fuse-linker-plugin -mfpmath=sse -Wl,-O1 -Wl,--sort-common -flto -fuse-linker-plugin CMakeFiles/cmake.dir/cmakemain.cxx.o CMakeFiles/cmake.dir/cmcmd.cxx.o -o ../bin/cmake libCMakeLib.a libCMakeServerLib.a libCMakeLib.a kwsys/libcmsys.a -ldl ../Utilities/std/libcmstd.a /usr/lib/libexpat.so /usr/lib/libz.so /usr/lib/libarchive.so /usr/lib64/libcurl.so /usr/lib64/libjsoncpp.so /usr/lib64/libuv.so /usr/lib64/librhash.so -lpthread /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/libexpat.so: error adding symbols: file in wrong format collect2: error: ld returned 1 exit status It's interesting, that some deps are correct and some are not: # grep /usr/lib CMakeCache.txt CURL_LIBRARY_RELEASE:FILEPATH=/usr/lib64/libcurl.so CURSES_CURSES_LIBRARY:FILEPATH=/usr/lib/libcurses.so CURSES_EXTRA_LIBRARY:FILEPATH=/usr/lib/libtinfo.so CURSES_FORM_LIBRARY:FILEPATH=/usr/lib/libform.so CURSES_NCURSES_LIBRARY:FILEPATH=/usr/lib/libncurses.so EXPAT_LIBRARY:FILEPATH=/usr/lib/libexpat.so JsonCpp_LIBRARY:FILEPATH=/usr/lib64/libjsoncpp.so LibArchive_LIBRARY:FILEPATH=/usr/lib/libarchive.so LibRHash_LIBRARY:FILEPATH=/usr/lib64/librhash.so LibUV_LIBRARY:FILEPATH=/usr/lib64/libuv.so ZLIB_LIBRARY_RELEASE:FILEPATH=/usr/lib/libz.so pkgcfg_lib_NCURSES_ncurses:FILEPATH=/usr/lib/libncurses.so pkgcfg_lib_NCURSES_tinfo:FILEPATH=/usr/lib/libtinfo.so pkgcfg_lib_PC_CURL_curl:FILEPATH=/usr/lib64/libcurl.so pkgcfg_lib_PC_EXPAT_expat:FILEPATH=/usr/lib/libexpat.so //Have library /usr/lib/libcurses.so //Have library /usr/lib/libncurses.so //Have library /usr/lib/libncurses.so FIND_PACKAGE_MESSAGE_DETAILS_CURL:INTERNAL=[/usr/lib64/libcurl.so][/usr/include][c ][v7.73.0()] FIND_PACKAGE_MESSAGE_DETAILS_Curses:INTERNAL=[/usr/lib/libncurses.so][/usr/include][v()] FIND_PACKAGE_MESSAGE_DETAILS_EXPAT:INTERNAL=[/usr/lib/libexpat.so][/usr/include][v2.2.10()] FIND_PACKAGE_MESSAGE_DETAILS_JsonCpp:INTERNAL=[/usr/lib64/libjsoncpp.so][/usr/include/jsoncpp][v1.9.4(1.4.1)] FIND_PACKAGE_MESSAGE_DETAILS_LibArchive:INTERNAL=[/usr/lib/libarchive.so][/usr/include][v3.4.3(3.3.3)] FIND_PACKAGE_MESSAGE_DETAILS_LibRHash:INTERNAL=[/usr/lib64/librhash.so][/usr/include][v()] FIND_PACKAGE_MESSAGE_DETAILS_LibUV:INTERNAL=[/usr/lib64/libuv.so][/usr/include][v1.40.0(1.10.0)] FIND_PACKAGE_MESSAGE_DETAILS_ZLIB:INTERNAL=[/usr/lib/libz.so][/usr/include][v1.2.11()] NCURSES_LIBDIR:INTERNAL=/usr/lib64 PC_CURL_LIBDIR:INTERNAL=/usr/lib64 PC_EXPAT_LIBDIR:INTERNAL=/usr/lib64 After rebuilding libz, libarchive and expat nothing changed. First idea was that there is some crap in pkgconfig, but looks like it's not that: # grep -e "/lib$" -e "/lib " /usr/lib64/pkgconfig/* /usr/lib64/pkgconfig/check.pc:libdir=${exec_prefix}/lib /usr/lib64/pkgconfig/gdal.pc:libdir=${exec_prefix}/lib /usr/lib64/pkgconfig/libbcc.pc:libdir=${exec_prefix}/lib /usr/lib64/pkgconfig/libcork.pc:libdir=${exec_prefix}/lib /usr/lib64/pkgconfig/libmosquitto.pc:libdir=${exec_prefix}/lib /usr/lib64/pkgconfig/libmosquittopp.pc:libdir=${exec_prefix}/lib /usr/lib64/pkgconfig/librtlsdr.pc:libdir=${exec_prefix}/lib /usr/lib64/pkgconfig/libtommath.pc:libdir=${exec_prefix}/lib /usr/lib64/pkgconfig/miniupnpc.pc:libdir=${exec_prefix}/lib /usr/lib64/pkgconfig/monodoc.pc:libdir=/usr/lib So, there is something wrong in the way cmake searches deps. Maybe I overlooked something reading the instruction? Reproducible: Always
Created attachment 670478 [details] portage/dev-util/cmake-3.18.4/temp/environment
Created attachment 670481 [details] emerge --info
Created attachment 670484 [details] CMakeCache.txt
Cmake can be built manually at this system (using ./bootstrap && gmake). So very likely something wrong with portage
Created attachment 670562 [details] cmake called manually find --debug-find Something wrong with search folders. Cmake was called with cmake --debug-find -C /tmp/portage/dev-util/cmake-3.18.4/work/cmake-3.18.4_build/gentoo_common_config.cmake -G "Unix Makefiles" -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_USE_SYSTEM_LIBRARIES=ON -DCMAKE_DOC_DIR=/share/doc/cmake-3.18.4 -DCMAKE_MAN_DIR=/share/man -DCMAKE_DATA_DIR=/share/cmake -DSPHINX_MAN=no -DSPHINX_HTML=no -DBUILD_CursesDialog=yes -DBUILD_TESTING=no -DCMAKE_BUILD_TYPE=Gentoo -DCMAKE_TOOLCHAIN_FILE=/tmp/portage/dev-util/cmake-3.18.4/work/cmake-3.18.4_build/gentoo_toolchain.cmake /tmp/portage/dev-util/cmake-3.18.4/work/cmake-3.18.4-C /tmp/portage/dev-util/cmake-3.18.4/work/cmake-3.18.4_build/gentoo_common_config.cmake -G "Unix Makefiles" -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_USE_SYSTEM_LIBRARIES=ON -DCMAKE_DOC_DIR=/share/doc/cmake-3.18.4 -DCMAKE_MAN_DIR=/share/man -DCMAKE_DATA_DIR=/share/cmake -DSPHINX_MAN=no -DSPHINX_HTML=no -DBUILD_CursesDialog=yes -DBUILD_TESTING=no -DCMAKE_BUILD_TYPE=Gentoo -DCMAKE_TOOLCHAIN_FILE=/tmp/portage/dev-util/cmake-3.18.4/work/cmake-3.18.4_build/gentoo_toolchain.cmake /tmp/portage/dev-util/cmake-3.18.4/work/cmake-3.18.4 2>&1 | tee log.txt
For this case I placed PATH=/usr/lib64:/lib64:$PATH for cmake into eclass.. PATH=/lib${libdir/lib}:/usr/lib${libdir/lib}:$PATH "${CMAKE_BINARY}" "${cmakeargs[@]}" "${CMAKE_USE_DIR}" || die "cmake failed" This is obviously horrible, but still better than having completely broken cmake.
It turns out, that LIB_SUFFIX -> CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX in gentoo_common_config.cmake fixes situation as well.
Title/summary: Please clarify that this is a /profile-/upgrade 17.0 -> 17.1 bug, not a some-package-17.x version upgrade bug. Maybe: Profile 17.1 upgrade: "error adding symbols: file in wrong format" for some dependencies Or "Profile 17.0 -> 17.1 upgrade:" if you want to keep the profile you upgraded from in there as well, but IMO the "profile" bit is more critical info than the 17.0 upgraded-from, and after that it's a question of title conciseness vs upgrade-from info, your call. (YMMV but it would have been useful here. Given the lack of domain specifier in the title and as a reasonably proactive ~arch user that switched to 17.1 profiles long ago, I'd guess three years ago in 2017 given the 17.x, I wasn't thinking about profiles, leaving me confused as to what package version 17.x you were referring to.)
*** Bug 753689 has been marked as a duplicate of this bug. ***
(In reply to Alexey Shevchuck from comment #0) > After rebuilding libz, libarchive and expat nothing changed. First idea was > that there is some crap in pkgconfig, > but looks like it's not that: > > # grep -e "/lib$" -e "/lib " /usr/lib64/pkgconfig/* > /usr/lib64/pkgconfig/check.pc:libdir=${exec_prefix}/lib > /usr/lib64/pkgconfig/gdal.pc:libdir=${exec_prefix}/lib > /usr/lib64/pkgconfig/libbcc.pc:libdir=${exec_prefix}/lib > /usr/lib64/pkgconfig/libcork.pc:libdir=${exec_prefix}/lib > /usr/lib64/pkgconfig/libmosquitto.pc:libdir=${exec_prefix}/lib > /usr/lib64/pkgconfig/libmosquittopp.pc:libdir=${exec_prefix}/lib > /usr/lib64/pkgconfig/librtlsdr.pc:libdir=${exec_prefix}/lib > /usr/lib64/pkgconfig/libtommath.pc:libdir=${exec_prefix}/lib > /usr/lib64/pkgconfig/miniupnpc.pc:libdir=${exec_prefix}/lib > /usr/lib64/pkgconfig/monodoc.pc:libdir=/usr/lib But all those paths are wrong.
Sure, but they are not related to this exact case
(In reply to Alexey Shevchuck from comment #0) > It's interesting, that some deps are correct and some are not: > > # grep /usr/lib CMakeCache.txt > ... Here's the result on my 17.1 system: CURL_LIBRARY_RELEASE:FILEPATH=/usr/lib64/libcurl.so CURSES_CURSES_LIBRARY:FILEPATH=/usr/lib64/libcurses.so CURSES_EXTRA_LIBRARY:FILEPATH=/usr/lib64/libtinfo.so CURSES_FORM_LIBRARY:FILEPATH=/usr/lib64/libform.so CURSES_NCURSES_LIBRARY:FILEPATH=/usr/lib64/libncurses.so EXPAT_LIBRARY:FILEPATH=/usr/lib64/libexpat.so JsonCpp_LIBRARY:FILEPATH=/usr/lib64/libjsoncpp.so LibArchive_LIBRARY:FILEPATH=/usr/lib64/libarchive.so LibRHash_LIBRARY:FILEPATH=/usr/lib64/librhash.so LibUV_LIBRARY:FILEPATH=/usr/lib64/libuv.so ZLIB_LIBRARY_RELEASE:FILEPATH=/usr/lib64/libz.so pkgcfg_lib_NCURSES_ncurses:FILEPATH=/usr/lib64/libncurses.so pkgcfg_lib_NCURSES_tinfo:FILEPATH=/usr/lib64/libtinfo.so pkgcfg_lib_PC_CURL_curl:FILEPATH=/usr/lib64/libcurl.so pkgcfg_lib_PC_EXPAT_expat:FILEPATH=/usr/lib64/libexpat.so //Have library /usr/lib64/libcurses.so //Have library /usr/lib64/libncurses.so FIND_PACKAGE_MESSAGE_DETAILS_CURL:INTERNAL=[/usr/lib64/libcurl.so][/usr/include][c ][v7.73.0()] FIND_PACKAGE_MESSAGE_DETAILS_Curses:INTERNAL=[/usr/lib64/libncurses.so][/usr/include][v()] FIND_PACKAGE_MESSAGE_DETAILS_EXPAT:INTERNAL=[/usr/lib64/libexpat.so][/usr/include][v2.2.10()] FIND_PACKAGE_MESSAGE_DETAILS_JsonCpp:INTERNAL=[/usr/lib64/libjsoncpp.so][/usr/include/jsoncpp][v1.9.3(1.4.1)] FIND_PACKAGE_MESSAGE_DETAILS_LibArchive:INTERNAL=[/usr/lib64/libarchive.so][/usr/include][v3.4.3(3.3.3)] FIND_PACKAGE_MESSAGE_DETAILS_LibRHash:INTERNAL=[/usr/lib64/librhash.so][/usr/include][v()] FIND_PACKAGE_MESSAGE_DETAILS_LibUV:INTERNAL=[/usr/lib64/libuv.so][/usr/include][v1.40.0(1.10.0)] FIND_PACKAGE_MESSAGE_DETAILS_ZLIB:INTERNAL=[/usr/lib64/libz.so][/usr/include][v1.2.11()] NCURSES_LIBDIR:INTERNAL=/usr/lib64 PC_CURL_LIBDIR:INTERNAL=/usr/lib64 PC_EXPAT_LIBDIR:INTERNAL=/usr/lib64 prefix_result:INTERNAL=/usr/lib64 So all is well, and you simply need to rebuild packages with an incorrect path in /usr/lib.
Well, as I wrote, I completed rebuild dependencies before writing this bug. Also, CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX works for me. What version of cmake do you have? I have 3.18.4. Do you have 32 bit versions of libexpat, zlib etc?
(In reply to Alexey Shevchuck from comment #13) > What version of cmake do you have? I have 3.18.4. Do you have 32 bit > versions of libexpat, zlib etc? Yes to all of that.
And you have LIB_SUFFIX (not CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX) in your gentoo_common_config.cmake which is generated by eclass? Then I don't get how this works. In cmake sources there is CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX. Source/cmFindLibraryCommand.cxx:53: // add custom lib<qual> paths instead of using fixed lib32, lib64 or // libx32 if (const char* customLib = this->Makefile->GetDefinition( "CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX")) { this->AddArchitecturePaths(customLib); }
Okay. I found out the problem, thanks to strace. it's a bit ... weird. Simply saying.. never ever create /etc/debian_version in gentoo. x_x
(In reply to Alexey Shevchuck from comment #16) > Okay. I found out the problem, thanks to strace. it's a bit ... weird. > > Simply saying.. never ever create /etc/debian_version in gentoo. > > x_x Similar issues arise with /etc/redhat-release; build systems make assumptions based on it. Don't do that!
You can follow bug 733480 for that; I haven't had time to follow up upstream about it.
