/usr/bin/ld: cannot find -l while compiling with gcc

I am writting an mqtt communication script where I am using the paho library. the files .so exist in the /home/chaima/paho.mqtt.c/build/output directory. but when trying to compile the code using the gcc compiler, I am getting this error

/usr/bin/ld: cannot find -l/home/chaima/paho.mqtt.c/build/output 

I've tried so many solutions but none of them worked for me. please if you need further information let me know about it. Thank you in advance.

2 Answers

The -l switch asks the linker to use a certain library. It should followed by the name of a library or a file system path to the library.

/home/chaima/paho.mqtt.c/build/output is a path to a directory, not a library.

The -L switch tells the linker to use a certain directory as a place to look in for libraries. After -L/A/B/C and -L/D/E/F, the linker will look in the directories /A/B/C and /D/E/F for libraries. For example, with -L/A/B/C -L/D/E/F -l foo, the linker will look for a file named /A/B/C/foo.extension and /A/B/C/foo.extension, where extension is one of the file name extensions used for libraries, such as a or so in foo.a or foo.so.

To get the linker to use your libraries in /home/chaima/paho.mqtt.c/build/output, use -L/home/chaima/paho.mqtt.c/build/output followed by -lName0 -lName1 -lName2 …, where Name0, Name1, Name2, and such are the names of your libraries. You an also ask the linker to use a library by giving its full path and name with no switch, as in /home/chaima/paho.mqtt.c/build/output/foo.so.

Both the ld command (to invoke the linker directly) and the gcc command (an overall command that will compile, link, and perform other tasks) accept these switches. In the future, read the manual page (also called the “man page”) or other documentation of the tools use use. The man page for ld explains what its -l and -L switches do. On Unix systems, you can usually see the man page for ld by executing man ld and the man page for gcc by executing man gcc. The current GCC documentation is also here.

My apologies if this response is not to the right thread, but it seems appropriate.

The order in which link_directories, add_executable and target_link_libraries are called plays a role.

I wasted two days trying to link a properly named and located libXX.so file because link_directories did not come before add_executable did not come before target_link_libraries.

Placing them in proper order resolved the problem. Curiously, cmake did not report that as an error or warning.

In my case the problem was amplified because the CMakeLists.txt file is managed by QTCreator and not fully under my control. My own CMakeLists.txt file worked, but not the one QT made and I modified (incorrectly.)