Cmake not compilled. TestLib trow error.

[maxim.251]

ssh2 in wrong format - that is in 32 bit where cmake needed 64 bit format odf that lib.

Background: I encountered a challenging issue while compiling CMake on Gentoo. The problem was associated with the libssh2 library, specifically related to ABI configurations and symbolic links. And TestLib.so throws compiling error and stopped compilation.

Initial Problem:
During the CMake compilation process, I received the following error:

Code: Select all

make[2]: *** No rule to make target '/usr/lib/libssh2.so', needed by 'bin/cmake'. Stop.

or similar.
This error indicated that the build process expected libssh2.so in /usr/lib, but the file was either not present or not correctly referenced.

Key Issue:
The original libssh2 installation was compiled with both ABI 64 and 32-bit support. However, CMake's build process was specifically looking for the 64-bit version of libssh2.so in the /usr/lib directory, where the 32-bit version was located.

Steps Taken to Resolve:

Unmerging libssh2:
As a first step, I unmerged libssh2 to remove the existing installation:

Code: Select all

sudo emerge --unmerge net-libs/libssh2

Re-emerging libssh2 with 64-bit ABI Only:
I then re-emerged libssh2 with only the 64-bit ABI enabled to ensure the correct version was installed: That is in /etc/portage/package.use.

Code: Select all

USE="abi_x86_64 -abi_x86_32" sudo emerge -av net-libs/libssh2

Adjusting Symbolic Links:
After re-emerging libssh2, I found that the symbolic link in /usr/lib was still pointing to the 32-bit version of the library. To resolve this, I removed the existing link and created a new one pointing to the 64-bit version in /usr/lib64:

Code: Select all

sudo rm /usr/lib/libssh2.so #if exist in that location
sudo ln -s /usr/lib64/libssh2.so /usr/lib/libssh2.so

Successful Compilation:
With the correct 64-bit version of libssh2 installed and the symbolic link properly set up in /usr/lib, the CMake compilation process completed successfully without further issues.

Conclusion:
This experience underscores the importance of ensuring that libraries are installed with the appropriate ABI settings and that symbolic links correctly reflect the expected library versions in Gentoo. By adjusting the ABI flags during the re-emergence of libssh2 and correcting the symbolic link in /usr/lib, I resolved the compilation issues and successfully built CMake.

I don't know why cmake was see 32 bit version in ssh2, but relinking did the magick. I have that problem from few years ago, and no one knows how to fixed it. Only message at the end of broken emerge shows that testlib broke the compilation, but because of earlier errors with ssh2 what compiler says that there is lib in wrong format.

[grknight]

Creating Symbolic Links:
After ensuring that libssh2 was correctly installed, I noticed that the symbolic link in /usr/lib pointing to the libssh2 library was missing. Since the CMake build was looking for libssh2.so in /usr/lib, I created the necessary symlink:

bash
Copy code

Code: Select all

sudo ln -s /usr/lib64/libssh2.so /usr/lib/libssh2.so

Successful Compilation:
With libssh2 correctly installed and the symlink in place, I was able to successfully compile CMake without further issues.

Conclusion:
This process highlights the importance of ensuring that libraries are correctly installed and referenced, especially in a Gentoo environment where ABI settings and library paths need to be carefully managed. By unmerging the problematic library, re-emerging with the correct ABI flags, and creating the required symbolic links, I was able to resolve the compilation issues and successfully build CMake.

Don't do this. You are setting yourself up for failure later. Please remove that symlink. Don't use --unmerge like this either.

Unless this is a musl or x32 (not x86_32) stage, find the real issue as a real amd64 install should be referencing /usr/lib64 not /usr/lib.

In additon, cmake does not depend on libssh2. So we need the build.log on whatever failed to know what the real issue is.

Also, stop using "sudo emerge" as it is likely blowing up from user environment bleed. Become root with either sudo -i or su -l then run emerge commands to ensure a clean build environment.

[maxim.251]

Why the Symlink Approach is Not Ideal:

In Gentoo, /usr/lib is conventionally used for 32-bit libraries, while /usr/lib64 is for 64-bit libraries on amd64 systems. By manually creating a symlink from /usr/lib64/libssh2.so (64-bit) to /usr/lib/libssh2.so, you might resolve the immediate issue, but it can cause confusion and potential conflicts with other packages that rely on the correct 32/64-bit separation. This approach is generally discouraged because it disrupts the system's standard library organization.
Finding the Real Issue:

The correct approach in a situation like this is to investigate why the build process was looking in /usr/lib for a 64-bit library. It could be due to an incorrect configuration or environment setting. For instance, there might be an issue with the LDFLAGS or PKG_CONFIG_PATH environment variables pointing to the wrong library path.
CMake and libssh2 Dependency:

As mentioned, CMake does not directly depend on libssh2. If a component of CMake was failing due to libssh2, it might be an indirect dependency or a specific feature of CMake requiring libssh2. Understanding the exact dependency chain can help address the root cause without resorting to manual workarounds like symlinks.
Advice on Using emerge:

Using sudo emerge can indeed cause issues due to environmental variables from the user's environment affecting the build process. It's recommended to become the root user with a clean environment (sudo -i or su -l) before running emerge commands. This ensures a stable and clean build environment.
Next Steps:

To proceed, you should remove the manually created symlink:

sudo rm /usr/lib/libssh2.so

Then, investigate the build process of CMake or the failing component to understand why it was looking for libssh2 in /usr/lib. The build.log file should contain detailed information about the failure and can guide you to the underlying issue.
Ensure your build environment is clean and your environment variables are correctly set to reference the appropriate library paths for a 64-bit build.
By addressing the root cause of the library path issue and ensuring a proper build environment, you can achieve a more stable and maintainable solution. This approach aligns with Gentoo's best practices and reduces the likelihood of encountering similar issues in the future.

Original code from compilation cmake with standard emerge. It shows that somehow cmake is depended by libssh2. And I am able to recreate that error, emerging again libssh2 with standard settings for gentoo. and then trying emerge cmake.

Code: Select all

[ebuild   R    ] net-libs/libssh2-1.11.0-r2::gentoo  USE="zlib -gcrypt -mbedtls -test" ABI_X86="32* (64) (-x32)" 0 KiB

Code: Select all

[ebuild   R    ] dev-util/cmake-3.27.7::gentoo  USE="ncurses -dap -doc -emacs -gui -qt6 -test -verify-sig" 0 KiB

This is error what I faced.

Code: Select all

[ 90%] Building CXX object Source/CMakeFiles/CTestLib.dir/CTest/cmCTestEmptyBinaryDirectoryCommand.cxx.o
cd /var/tmp/portage/dev-util/cmake-3.27.7/work/cmake-3.27.7_build/Source && /usr/bin/x86_64-pc-linux-gnu-g++  -I/var/tmp/portage/dev-util/cmake-3.27.7/work/cmake-3.27.7_build/Utilities -I/var/tmp/portage/dev-util/cmake-3.27.7/work/cmake-3.27.7/Source/CTest -I/var/tmp/portage/dev-util/cmake-3.27.7/work/cmake-3.27.7_build/Source -I/var/tmp/portage/dev-util/cmake-3.27.7/work/cmake-3.27.7/Source -I/var/tmp/portage/dev-util/cmake-3.27.7/work/cmake-3.27.7/Source/LexerParser -isystem /var/tmp/portage/dev-util/cmake-3.27.7/work/cmake-3.27.7/Utilities/std -isystem /var/tmp/portage/dev-util/cmake-3.27.7/work/cmake-3.27.7/Utilities -isystem /usr/include/jsoncpp  -pipe -march=native -std=c++17 -Wno-deprecated-declarations -MD -MT Source/CMakeFiles/CTestLib.dir/CTest/cmCTestEmptyBinaryDirectoryCommand.cxx.o -MF CMakeFiles/CTestLib.dir/CTest/cmCTestEmptyBinaryDirectoryCommand.cxx.o.d -o CMakeFiles/CTestLib.dir/CTest/cmCTestEmptyBinaryDirectoryCommand.cxx.o -c /var/tmp/portage/dev-util/cmake-3.27.7/work/cmake-3.27.7/Source/CTest/cmCTestEmptyBinaryDirectoryCommand.cxx
/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/libssh2.so: error adding symbols: file in wrong format
collect2: error: ld returned 1 exit status
make[2]: *** [Source/CursesDialog/CMakeFiles/ccmake.dir/build.make:321: bin/ccmake] Error 1
make[2]: Leaving directory '/var/tmp/portage/dev-util/cmake-3.27.7/work/cmake-3.27.7_build'
make[1]: *** [CMakeFiles/Makefile2:559: Source/CursesDialog/CMakeFiles/ccmake.dir/all] Error 2

Code: Select all

[ 86%] Building CXX object Source/CMakeFiles/CTestLib.dir/CTest/cmCTestCoverageCommand.cxx.o
cd /var/tmp/portage/dev-util/cmake-3.27.7/work/cmake-3.27.7_build/Source && /usr/bin/x86_64-pc-linux-gnu-g++  -I/var/tmp/portage/dev-util/cmake-3.27.7/work/cmake-3.27.7_build/Utilities -I/var/tmp/portage/dev-util/cmake-3.27.7/work/cmake-3.27.7/Source/CTest -I/var/tmp/portage/dev-util/cmake-3.27.7/work/cmake-3.27.7_build/Source -I/var/tmp/portage/dev-util/cmake-3.27.7/work/cmake-3.27.7/Source -I/var/tmp/portage/dev-util/cmake-3.27.7/work/cmake-3.27.7/Source/LexerParser -isystem /var/tmp/portage/dev-util/cmake-3.27.7/work/cmake-3.27.7/Utilities/std -isystem /var/tmp/portage/dev-util/cmake-3.27.7/work/cmake-3.27.7/Utilities -isystem /usr/include/jsoncpp  -pipe -march=native -std=c++17 -Wno-deprecated-declarations -MD -MT Source/CMakeFiles/CTestLib.dir/CTest/cmCTestCoverageCommand.cxx.o -MF CMakeFiles/CTestLib.dir/CTest/cmCTestCoverageCommand.cxx.o.d -o CMakeFiles/CTestLib.dir/CTest/cmCTestCoverageCommand.cxx.o -c /var/tmp/portage/dev-util/cmake-3.27.7/work/cmake-3.27.7/Source/CTest/cmCTestCoverageCommand.cxx
/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/libssh2.so: error adding symbols: file in wrong format
collect2: error: ld returned 1 exit status
make[2]: *** [Source/CMakeFiles/cmake.dir/build.make:126: bin/cmake] Error 1
make[2]: Leaving directory '/var/tmp/portage/dev-util/cmake-3.27.7/work/cmake-3.27.7_build'
make[1]: *** [CMakeFiles/Makefile2:473: Source/CMakeFiles/cmake.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

exact this line

/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/libssh2.so: error adding symbols: file in wrong format

I know that normally I do not want mess wit libs but that case was making me crazy from few years, last time I did update system by skipping cmake, and installing it manually from /var/tmp/portage/dev-util/cmake-... using ./configure ; make ; make install ; But system still see old version for updating. This time I found solution to emerge everything and solve problem to cmake.

[maxim.251]

and this is my make.conf

Code: Select all

COMMON_FLAGS="-pipe -march=native" # "-O2 -pipe -march=native"
CFLAGS="${COMMON_FLAGS}"
CXXFLAGS="${COMMON_FLAGS}"
FCFLAGS="${COMMON_FLAGS}"
FFLAGS="${COMMON_FLAGS}"
CHOST="x86_64-pc-linux-gnu"
#CMAKE_EXTRA_FLAGS="-DCMAKE_INSTALL_PREFIX:PATH=~/local"


MAKEOPTS="-j6"
# NOTE: This stage was built with the bindist Use flag enabled
PORTDIR="/usr/portage"
DISTDIR="/usr/portage/distfiles"
PKGDIR="/usr/portage/packages"

CPU_FLAGS_X86 = "3dnow 3dnowext mmx mmxext popcnt sse sse2 sse3 sse4a"

# This sets the language of build output to English.
# Please keep this setting intact when reporting bugs.
LC_MESSAGES=C

USE="3dnow 3dnowext 7zip a52 alsa alsa-plugin analyzer appindicator \
     bluetooth bluray cdaudio cpudetection cuda cycles dbus device-mapper \
     dts dvb equalizer ext2 ext4 fam ffmpeg firmware fontconfig gzip hpcups \
     hpijs http http2 ico jpeg jpeg2k libusb0 lvm lvm2create_initrd lzma lzo \
     minizip mp3 mpeg mtp networkmanager ntfs nvdec nvenc nvidia png \
     printsupport pulseaudio qml scanner sensord server snmp sound svg \
     system-lz4 thread-safety threaded threads upower usb vcd vdpau widgets \
     x264 x265 x86-64 xvmc youtube -dri -gles -gles2-only -gpm -handbook \
     -harfbuzz -icu -libaom -libav -libav-aac -lua -static -static-libs \
     -wayland chromium jack"

#printer
SANE_BACKENDS="hp"
#GRUB_PLATFORMS="efi-64"
ABI_X86="32 64" #-x32 -64
## (For mouse, keyboard, and Synaptics touchpad support)
INPUT_DEVICES="libinput synaptics evdev"
## (For NVIDIA cards)
VIDEO_CARDS="nvidia virtualbox"

PYTHON_TARGETS="python3_10" # python3_11"
PYTHON_SINGLE_TARGET="python3_10" # python3_11" #python3_6

EMERGE_DEFAULT_OPTS=" --keep-going "#--with-bdeps=y"
RUBY_TARGETS="ruby25 ruby26"

[maxim.251]

Replacing

/usr/lib/libssh2

using

/usr/lib64/libssh2

again I have succeeded compilation of cmake. Only cmake faced that problem. Now I have cmake in newest stable version.
Ps. I try install all available versions and all of them get same error. It is wired that not many peoples have that problem and it is not usual to get error emerging cmake. And that cmake need libssh2 . And after 2 years later I did find that exact problem, before I was waiting for update of cmake, believing that maybe there was a bug and it will be fixed soon. But no. And to day after almost 12 hours of trying and research i found it, and I get emerging cmake get to work.

[grknight]

I get the feeling at least some of this was written by a bot or bad translator.

I am confused what the question is now, if this is solved and if there is more to do.

[maxim.251]

I get the feeling at least some of this was written by a bot or bad translator.

I am confused what the question is now, if this is solved and if there is more to do.

Yes, sorry... I use chat Gpt3 and I have short time to check text.
Solution was to replace lib in /usr/lib/... with 64bit version, because cmake was looking for it in 32 bit version in my system. rather to check in /usr/lib64/... This problem is now from 2 or even 3 tears now. those who have only 64bit system, and not multisystem like me, don't have that problem. First time when it happened, I was believing that not all packages are up to date against cmake, or cmake have bug related to old packages removed and not needed by gentoo, but after few years problem still remain. And that forced me to make deeper research. At the end I found that is looking for libs in wrong spot on my system. Only solution in my opinion without messing in config files was simply copying linking from lib64 to lib, and cmake successfully compiled without any problems.
And because it was not easy to find in logs of compilation, I want to share with everybody with that problem.

[grknight]

I get the feeling at least some of this was written by a bot or bad translator.

I am confused what the question is now, if this is solved and if there is more to do.

Yes, sorry... I use chat Gpt3 and I have short time to check text.
Solution was to replace lib in /usr/lib/... with 64bit version, because cmake was looking for it in 32 bit version in my system. rather to check in /usr/lib64/... This problem is now from 2 or even 3 tears now. those who have only 64bit system, and not multisystem like me, don't have that problem. First time when it happened, I was believing that not all packages are up to date against cmake, or cmake have bug related to old packages removed and not needed by gentoo, but after few years problem still remain. And that forced me to make deeper research. At the end I found that is looking for libs in wrong spot on my system. Only solution in my opinion without messing in config files was simply copying linking from lib64 to lib, and cmake successfully compiled without any problems.
And because it was not easy to find in logs of compilation, I want to share with everybody with that problem.

Please don't feed a Chat bot these bad answers. They are wrong and harmful to others.

Solve the real problem and not copy such things as it will only be worse later.

[olivier-lonzi]

I have the same issue since febuary 2023, and the solution on this thread viewtopic-t-1170229.html?sid=2c1d8ffe88 ... 0847367c58 fix the issue.

I share here, because I already try to do it the way of maxim.251, and have issues quickly after + I am agree with grknight changing symlink in /lib* was not a good solution at first.

The solution in viewtopic-t-1170229.html?sid=2c1d8ffe88 ... 0847367c58 was so simple and seems happen to old gentoo instance, with weird files.