| View previous topic :: View next topic |
| Author |
Message |
maxim.251
Tux's lil' helper
Joined: 14 Jul 2012
Posts: 127
|
 Posted: Wed Dec 20, 2023 7:40 pm Post subject: Cmake not compilled. TestLib trow error. |
 |
|
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: | | 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: | | 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: | | 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: | 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.
Last edited by maxim.251 on Wed Dec 20, 2023 8:10 pm; edited 1 time in total |
|
| Back to top |
|
 |
grknight
Retired Dev
Joined: 20 Feb 2015
Posts: 1951
|
| Posted: Wed Dec 20, 2023 7:57 pm Post subject: Re: Cmake not compilled. TestLib trow error. |
|
|
| maxim.251 wrote: | 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: | | 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. |
|
| Back to top |
|
|
maxim.251
Tux's lil' helper
Joined: 14 Jul 2012
Posts: 127
|
| Posted: Wed Dec 20, 2023 8:44 pm Post subject: |
|
|
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:
| Quote: | | 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: | [ebuild R ] net-libs/libssh2-1.11.0-r2::gentoo USE="zlib -gcrypt -mbedtls -test" ABI_X86="32* (64) (-x32)" 0 KiB
|
| Code: | [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: |
[ 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: |
[ 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 | Quote: | | /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. |
|
| Back to top |
|
|
maxim.251
Tux's lil' helper
Joined: 14 Jul 2012
Posts: 127
|
| Posted: Wed Dec 20, 2023 8:48 pm Post subject: |
|
|
and this is my make.conf
| Code: | 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"
|
|
|
| Back to top |
|
|
maxim.251
Tux's lil' helper
Joined: 14 Jul 2012
Posts: 127
|
| Posted: Wed Dec 20, 2023 8:59 pm Post subject: |
|
|
Replacing using | Quote: | | /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. |
|
| Back to top |
|
|
grknight
Retired Dev
Joined: 20 Feb 2015
Posts: 1951
|
| Posted: Wed Dec 20, 2023 9:10 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
maxim.251
Tux's lil' helper
Joined: 14 Jul 2012
Posts: 127
|
| Posted: Fri Dec 22, 2023 6:15 am Post subject: |
|
|
| grknight wrote: | 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. |
|
| Back to top |
|
|
grknight
Retired Dev
Joined: 20 Feb 2015
Posts: 1951
|
| Posted: Fri Dec 22, 2023 1:42 pm Post subject: |
|
|
| maxim.251 wrote: | | grknight wrote: | 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. |
|
| Back to top |
|
|
olivier-lonzi
n00b
Joined: 25 Nov 2012
Posts: 4
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
