I've installed libcrypto++-dev and crypto1 besides their 32-bit versions ( since I think the program I'm trying to compile needs them). But still I get the following error :
/usr/bin/ld: Cannot find -lcrypto
Any suggestions ?
I use ubuntu 18.04
The linker would be unable to find something like libcrypto.so.1 based on the combo of default/configured and arg-based set of directories to search.
Most likely your lib resides in a dir outside of the linker's default list.
After identifying the lib install dir, replace /usr/local/lib64 within this example:
gcc <list-of-objects> -o xyz -L/usr/local/lib64 -lcrypto
Related
How do I get my 'make' process to show me the actual search paths and libraries found with the linker?
I have link errors for symbols I know are in libraries I am trying to use ( verified using objdump ). What I don't know is if the linker is finding the correct libraries. It should be, since all of the libraries I am using are in one directory and some of them ARE being found and used.
So I would like to get diagnostic output showing what library search paths were used, and what libraries ( with paths ) that were actually found and used by the linker.
I tried make -n and got
g++ -g -Wall -DLINUX -I../../../Common/include -I../../../Common/libs/liblua/src main.o IDUpdater.o version.o -L../../../Common/libs -lapp -lserver -lthreading -lnet -lmsgqueue -lcpp -lisam -lisamcore -ldb -ldbisam -ldbsql -Wl,--whole-archive -Wl,--no-whole-archive -o foo
I know libisam.a ,libdbisam.a and others are found and used, but libmsgqueue.a is not. These libraries are all in ../../..'Common/libs/.
Please help me about problems when i try build Skia by this guide
It said that:
/usr/bin/ld: cannot find -lfreetype
/usr/bin/ld: cannot find -lfontconfig
/usr/bin/ld: cannot find -lGL
/usr/bin/ld: cannot find -lGLU
/usr/bin/ld: cannot find -lX11
Thank's so much!
/usr/bin/ld is the linker: it links the program you are trying to compile with existing libraries. In your case, those libraries will be files named libfreetype.so, libfontconfig.so, and so on.
The problem in your case is probably those libraries don't exist on your system. So you must install them. The process for doing so varies depending on which version of Linux you are running.
On a Redhat, CentOS or Fedora based system, the process would be to do something like
yum -y install "*freetype*"
Look at the output of 'yum list' to find the exact name. If you're on another type of Linux, perhaps someone else can help.
I'm having some linker trouble on linux with my cmake project.
I've installed a package (nvidias Cg toolkit) which puts the library files in /usr/lib64
I use the find script here: http://code.google.com/p/nvidia-texture-tools/source/browse/branches/2.0/cmake/FindCg.cmake?r=452
If I print out CG_LIBRARY and CG_GL_LIBRARY with message() after running the find script they are both set to the correct file and path:
/usr/lib64/libCg.so-lpthread
/usr/lib64/libCgGL.so
The find script adds -lpthread to CG_LIBRARY. I've also tried removing the line where it adds this and add it manually to the target project.
Then I add these variables to the target project with target_link_libraries().
When I run make it says:
/usr/bin/ld: cannot find -lCg
/usr/bin/ld: cannot find -lCgGL
collect2: error: ld returned 1 exit status
Now if I run make with VERBOSE=1 I can see that there is no -L/usr/lib64 entry. If I edit the CMakeFiles/MyProject.dir/link.txt and add the entry manually it links it fine. Shouldn't cmake add the -L entries automaticaly with target_link_libraries()?
I've also tried using link_directories to add the -L manualy, but that doesn't do anything either..
This question already has answers here:
How to link to a shared library without lib* prefix in a different directory? [duplicate]
(2 answers)
Closed 2 years ago.
I compiled a few libraries using Eclipse-CDT on windows. However, when I tried to compile them under linux gcc keeps giving me the error /usr/bin/ld: cannot find -lrequestedLib. I'm using the exact same build settings between the two environments (namely I made sure to add the directories that contain the libraries i need to link to). I'm sure the system has read access rights to the files as well. I'm not sure what to make of this. Please help.
Edit: These are the commands that ecplise runs to build the library:
gcc -I/home/me/lib/ -O3 -Wall -c -fmessage-length=0 -olibToMake.o ../libToMake.c
gcc -L/home/me/lib/ -shared -olibToMake.so libToMake.o -lrequestedLib
Edit 2: The command that renders the error is the second of the two, resulting in the /usr/bin/ld: cannot find -lrequestedLib being output.
Edit 3: I've confirmed that requestedLib.so is a x86_64 binary.
If you don't want to pass -L command line options to gcc(1), be sure to add the path containing the libraries to /etc/ld.so.conf or /etc/ld.so.cond.d/<something>.
Once you've installed your libraries you also need to run ldconfig(8) by hand. (Most new users forget this step because typical package managers take care of this for you when installing new libraries.)
gcc -I/home/me/lib/ -O3 -Wall -c -fmessage-length=0 -olibToMake.o ../libToMake.c
gcc -L/home/me/lib/ -shared -olibToMake.so libToMake.o -lrequestedLib
When building 64-bit shared libraries on x86_64, the -fPIC flag is usually required, or you get a recompile with -fPIC error at shared library link time.
Since you didn't use -fPIC, yet your link succeeded, you are likely using (non-default) gcc that targets i*86 (that is, produces 32-bit output). You can confirm that by running file libToMake.so.
You didn't show that command that actually fails (the one that produces cannot find -lrequestedLib error). I am guessing that that command is using a different gcc (default one?), that targets x86_64. If it looks something like
gcc main.c -L/home/me/lib -lrequestedLib
that command will ignore /home/me/lib/librequestedLib.so (because you can't link together 32-bit and 64-bit code), and will continue searching for librequestedLib elsewhere. When it can't find a 64-bit version of librequestedLib, it will produce the error message you are gettiing.
I have downloaded the latest GLUI source code and now I am trying to compile it. When I do so, I get the following error:
g++ -O0 -Wall -pedantic -I./ -I./include -I/usr/X11R6/include -o bin/example1 example/example1.cpp -L./lib -lglui -L/usr/X11R6/lib/libXdmcp.a -lglut -lGLU -lGL -lXmu -lXext -lX11 -lXi -lm
/usr/bin/ld: cannot find -lXmu
collect2: ld returned 1 exit status
When I did a locate libXmu, I get the following output:
> %:~/src/GLUI/src$ locate libXmu
> /usr/lib/libXmu.so.6
> /usr/lib/libXmu.so.6.2.0
> /usr/lib/libXmuu.so.1
> /usr/lib/libXmuu.so.1.0.0
Do I get the error because I don't have a /usr/lib/libXmu.so? If this is the case, how can I make one? (I am not experienced with linking at all).
Thanks!
Linux distributions usually package the libraries needed for running programs separately from the files needed to build programs.
Look for packages named *-devel or *-dev.
I don't know which one you need in particular for this, but you can use apt-cache search to look for it.
The answer was actually one of the first ones here originally but the owner deleted it, it seems. I was able to solve the problem by creating a symbolic link to the latest version of the library (i.e. /usr/lib/libXmu.so.6) and compile the code successfully.
I had the same problem, if creating a symbolic link doesnt help,
try the following:
Print your $PATH ("echo $PATH"),
and check if the library file you need is in one of those directories.
Use "export PATH=/newly/added/path:$PATH" to add new directory to check.
Ive been including libevent, added "-levent" in the gcc command, and ld used file /usr/lib/libevent.so, so it looks like the "lib" prefix and extension are being added automatically by ld.
Keep it up.