I'm trying to build Teigha SDK in Ubuntu 12.04. I got the following linking error:
/usr/bin/ld: cannot find -lJpeg
/usr/bin/ld: cannot find -lJpeg
libjpeg has alredy been installed on my machine. What else is missing?
libjpeg has alredy been installed on my machine. What else is missing?
/usr/bin/ld: cannot find -lJpeg
^
Note the uppercase letter! The linker is missing a libJpeg.a (or other archive format) file, or an appropriate -L<path> option to resolve it.
Related
While attempting to write a kernel in C++, I've run into a peculiar issue.
When prompting g++ to compile even a very basic C++ file statically and to binary, it simply keeps skipping over the static math library (libm.a), ultimately failing to compile.
Attempting to compile a simple C++ file:
test.cpp
int main() {
return 0;
}
using this g++ command:
g++ -static test.cpp -Wl,--oformat=binary
I receive the following error output:
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu/libm.a when searching for -lm
/usr/bin/ld: skipping incompatible /lib/x86_64-linux-gnu/libm.a when searching for -lm
/usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libm.a when searching for -lm
/usr/bin/ld: skipping incompatible /lib/x86_64-linux-gnu/libm.a when searching for -lm
/usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libm.a when searching for -lm
/usr/bin/ld: cannot find -lm: No such file or directory
I am running Linux Mint Cinnamon V. 21 (Vanessa) on a VirtualBox VM.
In my attempt to narrow down the issue, I have also attempted to exclude the -static flag:
g++ test.cpp -Wl,--oformat=binary
Which results in a different error entirely:
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/11/libstdc++.so: error adding symbols: file in wrong format
collect2: error: ld returned 1 exit status
After thorough research, I was made aware that this could be caused by an incompatibility between 32-bit libraries and 64-bit files. Everything is supposed to be in 64 bit.
I did attempt to determine bitness of libm.a using file.
When using the file command on /usr/lib/x86_64-linux-gnu/libm.a, I receive the following output:
libm.a: ASCII text
indicating neither bitness. This led me to conclude that perhaps the library is damaged and needs updating. After running sudo apt-get install libc6-dev, the issue persists, however.
I'm not sure what to do at this point.
Update:
I've opened libm.a in a text editor and the entire contents of the file are:
/* GNU ld script
*/
OUTPUT_FORMAT(elf64-x86-64)
GROUP ( /usr/lib/x86_64-linux-gnu/libm-2.35.a /usr/lib/x86_64-linux-gnu/libmvec.a )
Update 2: apparently this is a linker script. Both referenced files libm-2.35.a and libmvec.a are present in my directory and are, according to objdump, 64-bit-versions.
Based on the compiler's error output, it seems that in my case, for whatever reason, g++ (or more specifically, ld) fails to use this linker script. What could possibly cause this?
I have come to the conclusion that it is not normally possible to statically link C++ code involving object oriented features into a fully functional binary file, as libm.a can apparently be linked to ELF only.
besides: even the static version of glibc, which is also required, references other dynamic libraries, making it useless for kernel code.
there might be some sort of workaround, but it seems that g++ does not support this functionality by default.
I am getting a error when I try to compile some c++ code using the olcPixelGameEngine as a header file, the error is -
/usr/bin/ld: cannot find -lGL
/usr/bin/ld: cannot find -lpng
Depending on the code being compiled, the error message may look like:
/usr/bin/ld: cannot find -lc
/usr/bin/ld: cannot find -lltdl
/usr/bin/ld: cannot find -lXlst
The xxx represents the name of the library, for example, libc.so, libltdl.so, libXtst.so. The naming rule is: lib + library name (i.e. xxx) + .so.
There are 3 possible reasons for such error to occur:
The lib is not installed in the system;
Incorrect version of the installed lib;
Incorrect symbolic link for the lib (.so file). The link is not linked to the correct .so file.
Solutions:
Check whether the symbolic link is correctly linked to the .so file in /usr/lib and correct any incorrect link.
For example,
If the error message "/usr/bin/ld: cannot find -lXlst" is caused by incorrect symbolic link, issue the commands below to correct it.
cd /usr/lib
ln -s libXtst.so.6 libXtst.so
If the problem is not caused by incorrect symbolic link, then it's likely caused by missing lib. In this case, missing lib needs to be installed.
For example,
If the error message "/usr/bin/ld: cannot find -lXlst" is caused by missing "libXtst.so" under "/usr/lib", issue the command below to install it.
apt-get install libxtst-dev
Additional note on how to install the missing lib.
Identify the missing lb
Error Message Missing lib
/usr/bin/ld: cannot find -lc ---------------------------------------------------->libc
/usr/bin/ld: cannot find -lltdl ---------------------------------------------------->libltdl
/usr/bin/ld: cannot find -lXlst ----------------------------------------------------> libXtst
Search for the missing lib
apt-cache search libc-dev
apt-cache search libltdl-dev
apt-cache search libXtst-dev
Install the missing lib.
please refer below link. this might help.
http://wei48221.blogspot.com/2017/08/linux-how-to-solve-problem-of-usrbinld.html
I am getting these errors
`/usr/bin/ld: cannot find -lQt5::Core /usr/bin/ld:
cannot find -lQt5::Gui /usr/bin/ld:
cannot find -lQt5::Widgets /usr/bin/ld:
cannot find -lQt5::Test /usr/bin/ld:
cannot find -lQt5::Concurrent /usr/bin/ld:
cannot find -lQt5::OpenGL collect2: error: ld`
when i am makeing the project [https://github.com/estranho/facialSketchRecognition] .When i am making without ENABLE_SAMPLES i fotn get any error but when building Samples i m getting these errors.
https://github.com/estranho/facialSketchRecognition the project readme says cmake.. and make thats it but couldnt run any executable so building Samples is needed.
You must:
either install globally the Qt5 development library
define your LD_LIBRARY_PATH to allow the system to find the Qt5 library, when performing the linking step (which is exactly what /usr/bin/ld is trying to do)
Under Ubuntu the package is named qtdeclarative5-dev.
I'm currently using Fedora 20 x86_64.
I've built libsndfile with these commands:
sudo ./configure BASE_FLAGS=-32
sudo make
sudo make install
This all goes well and I can find the compiled library in /usr/local/lib.
I want to use this in an application that will be built in 32bit.
The problem occurs when I try to compile that application. I get the following error:
/usr/bin/ld: skipping incompatible /builddir/Code/Platformer/../Dependencies/libsndfile/lib/Linux/libsndfile.so when searching for -lsndfile
/usr/bin/ld: skipping incompatible /builddir/Code/Platformer/../Dependencies/libsndfile/lib/Linux/libsndfile.a when searching for -lsndfile
/usr/bin/ld: cannot find -lsndfile
The "skipping incompatible" might suggest that I'm doing something wrong when compiling sndfile but since I'm kind of new to this I can't find what it is. I tried different configurations but they all have the same result.
If this needs more code or something, let me know what you need.
For anyone with the same problem - try to look here:
ld cannot find an existing library
Generally there is probably a symlink missing, because the '-devel' library is not istalled. That is why
sudo yum install libsndfile-devel.*
fixed it for me.
I am trying to build a small Qt (C++) GUI application on Linux but it fails to build with numerous linker errors, complaining about missing dependencies for the Qt library I am linking against. I used ldd on the Qt libraries to verify that the libraries are indeed there - and they are.
My problem seems to be related to the discussion in this thread:
Linking dependencies of a shared library
And while that thread helped me identify my precise problem, it seems that the conclusion of that thread was that my application should link!
The application is compiled with the following command:
g++ -m64 -Wl,-O1 -o Executable some-object.o some-other-object.o -lQtCore -lQtGui -lQtXml -L/usr/lib64 -L/usr/X11R6/lib64 -lpthread
Running this generates warnings of the following form, and linking eventually fails with undefined reference errors (to symbols defined in the 'missing' libraries):
.../ld: warning: libglib-2.0.so.0, needed by /usr/lib64/libQtGui.so, not found (try using -rpath or -rpath-link)
.../ld: warning: libpng14.so.14, needed by /usr/lib64/libQtGui.so, not found (try using -rpath or -rpath-link)
.../ld: warning: libz.so.1, needed by /usr/lib64/libQtGui.so, not found (try using -rpath or -rpath-link)
.../ld: warning: libfreetype.so.6, needed by /usr/lib64/libQtGui.so, not found (try using -rpath or -rpath-link)
and so on (in total there are 18 dependencies that could not be found.)
I can get this to compile if I go and explicitly add -lglib, -lpng14, -lz -lfreetype and so on, but as I mentioned there are 18 dependencies - and I would rather not do that. It also seems that I should not have to do it.
I have compiled the same project on my laptop computer which uses the exact same Linux Distro (openSuse 12.2) without any troubles. All libraries, including Qt, were installed from the distro repositories.
I think this might be some sort of setup problem on my openSuse install, but I have no idea where to start looking to fix this.
Cheers,
Craig
It appears that /usr/lib64/libQtGui.so have hardcoded rpaths in them to locate dependent shared libraries. On one of your hosts the needed libraries are in the expected location while on the other host they are not.
You can use something like elfdump to get the RPATH out of the QT shared library to find out where it will look. Then you can use (I believe) -R on your link command line to point it to where the libraries are actually installed on that host.
EDIT: I think you can do something like objdump -x <binary/library> | grep -i rpath