I am trying to install the xlnt library on Ubuntu 18. I have installed xlnt exactly as the instructions say on the repo. When I try to compile my code, the following error pops up:
/usr/bin/ld: cannot find -lxlnt
collect2: error: ld returned 1 exit status
makefile:204: recipe for target 'BOF-debug-static' failed
make: *** [BOF-debug-static] Error 1
I have been installing other libraries to get the code working, and I've noticed that the other libraries are creating .a files at /usr/local/lib along with a few other .la, and .so files. When I install xlnt, it is not creating any .a files, but does create a .so and .so.1.2 files. Not sure if that is relevant, but it's something I've noticed.
How do I make xlnt discoverable to g++ and get the -lxlnt flag to work?
The target you are building BOF-debug-static is evidently one that requests
either a fully static linkage, with the -static linkage option, or possibly one that
requests static linkage specifically of libxlnt, with a linkage option such as:
-Wl,-Bstatic -lxlnt -Wl,-Bdynamic
Since, as you observed, libxlnt by default provides only a shared/dynamic library libzlint.so ( -> libzlint.so.X.Y.Z),
and no static library libzlnt.a, the linker ignores the the shared library when
required to link -lxlnt statically and says:
/usr/bin/ld: cannot find -lxlnt
You cannot link a shared library statically.
However, if you configure the CMake build system with:
cmake -DSTATIC=ON [your previous options...]
then make will build a static library and running make install (as root) will create /usr/local/lib/libxlnt.a.
Related
I have a vulkan project that is trying to use shaderc.
The library was installed under the following path (linux system):
./libraries/shaderc/build/libshaderc
Doing ls in this directory gives:
CMakeFiles shaderc_combined_shaderc_test
cmake_install.cmake shaderc_c_smoke_test
CTestTestfile.cmake shaderc_shaderc_cpp_test
libshaderc.a shaderc_shaderc_private_test
libshaderc_combined.a shaderc_shaderc_test
libshaderc_shared.so shaderc_shared_shaderc_cpp_test
libshaderc_shared.so.1 shaderc_shared_shaderc_private_test
shaderc_combined.ar shaderc_shared_shaderc_test
shaderc_combined_shaderc_cpp_test
The documentation provided with the library explicitly states:
If the external project does not use CMake, then the external project can instead directly use the generated libraries.
shaderc/libshaderc/include should be added to the include path, and
build/libshaderc/libshaderc_combined.a should be linked. Note that
on some platforms -lpthread should also be specified.
I attempt to link the project as follows using make:
g++ -o "../build/VulkanEngine" obj/Debug/DebugCallback.o obj/Debug/Device.o obj/Debug/log.o obj/Debug/ImageViews.o obj/Debug/Instance.o obj/Debug/Pipeline.o obj/Debug/RenderPass.o obj/Debug/Surface.o obj/Debug/SwapChain.o obj/Debug/VkExtensionsStubs.o obj/Debug/GLFW_tools.o obj/Debug/main.o -L../libraries/glfw-3.2.1/bin -L../libraries/glm/bin/glm -L../libraries/vulkansdk-linux/1.1.97.0/x86_64/lib -L../libraries/shaderc/build/libshaderc -lstdc++fs -lglfw -lglm_static-lvulkan -llibshaderc_combined.a
In particular notice the argument -L../libraries/shaderc/build/libshaderc: and the argument -llibshaderc_combined.a
As you can see the specified linking path matches the installation path (libraries/ contains all the third party libraries my project uses).
However the linker complains:
/usr/bin/ld: cannot find -llibshaderc_combined.a
collect2: error: ld returned 1 exit status
make[1]: *** [VulkanEngine.make:119: ../build/VulkanEngine] Error 1
make: *** [Makefile:30: VulkanEngine] Error 2
So it seems I messed up the path somehow, but I don;t know how.
The -lname linkage option directs the linker to search in specified
(-Ldir) and default library search directories for either of the
files libname.so (shared library) or libname.a (static library). If it finds either of them them it searches
no more directories and inputs that file to the linkage. If it finds
both of them in the same search directory then it will prefer libname.so.
So change:
-llibshaderc_combined.a
to:
-lshaderc_combined
You must also be sure that -lshaderc_combined appears in the linkage
sequence before any other library that it depends on, and after any object file or library that depends upon it, or the linkage
is liable to fail with undefined reference errors.
I am using netbeans on redhat. I have a suite of related projects:
stand alone .a utility library
stand alone project specific .a library
executable that depends on the two .a libs and a couple third
party shared and static libs
a .so module that depends on the two .a libs and a couple third
party shared and static libs
My goal is that the executable and the module will be easily copied onto target machines here to do the necessary tasks without having to make sure that the associated local and third party libs are installed as well.
The executable builds and seems to work fine. The .so module builds fine but the application that loads it finds undefind references to various things. I have found advice that says to surround the list of needed libraries with
g++ ... -Wl,--whole-archive -llib1 -llib2 ... -Wl,--no-whole-archive
I just discovered that you add this in netbeans by going to {project} > Properties > Linker > Libraries; editing the list of libraries; and then, Add Option to add the strings. Then you use the Up/Down buttons to position the whole-archive options where you want them. Cool!
The result of this however is:
g++ -o dist/Debug/GNU_1-Linux-x86/myLocalSharedObjectModule.so build/Debug/GNU_1-Linux-x86/myLocalSharedObjectModule.o -L/usr/local/myLibTestDestination -Wl,--whole-archive -lpam -lpcre -lsqlite3 /usr/lib64/mysql/libmysqlclient.a -lmyLib-1 -lmyLib-2 -Wl,--no-whole-archive -shared -fPIC
/usr/lib64/mysql/libmysqlclient.a(mysys_dtrace.o):(.SUNW_dof+0x0): multiple definition of `__SUNW_dof'
/usr/lib64/mysql/libmysqlclient.a(clientlib_dtrace.o):(.SUNW_dof+0x0): first defined here
/usr/bin/ld: Warning: size of symbol `__SUNW_dof' changed from 4050 in /usr/lib64/mysql/libmysqlclient.a(clientlib_dtrace.o) to 4274 in /usr/lib64/mysql/libmysqlclient.a(mysys_dtrace.o)
/usr/lib64/mysql/libmysqlclient.a(mysys_ssl_dtrace.o):(.SUNW_dof+0x0): multiple definition of `__SUNW_dof'
/usr/lib64/mysql/libmysqlclient.a(clientlib_dtrace.o):(.SUNW_dof+0x0): first defined here
/usr/bin/ld: Warning: size of symbol `__SUNW_dof' changed from 4274 in /usr/lib64/mysql/libmysqlclient.a(clientlib_dtrace.o) to 3490 in /usr/lib64/mysql/libmysqlclient.a(mysys_ssl_dtrace.o)
collect2: ld returned 1 exit status
I'm not sure what to do about this. Is it actually possible to link static (mysql and my libs) and shared (sqlite3, pcre, ...) objects into a shared object?
I am trying to use the libsodium library in a C++ project and I'm having difficulty with linking the static Libsodium Library into a Shared Object that I've created. This project is being compiled using G++ and is set to use C++11 Standards.
After reading various forum posts about linking a Static Library into a Shared Object, I've tried using the Whole Archive which seems to get me further but still will not link in correctly.
The following is the Command being used to link:
/usr/bin/g++ -shared -fPIC -o ./Debug/libwowcrypt.so #"libwowcrypt.txt" -L. -L../SharedLibraries/Sodium/lib -Wl,--whole-archive -lsodium -Wl,--no-whole-archive
The following error messages are returned from ld:
/usr/bin/ld: ../SharedLibraries/Sodium/lib/libsodium.a(libsodium_la-hmac_hmacsha256.o): relocation R_X86_64_PC32 against symbol `crypto_auth_hmacsha256_init' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
Can anyone advise on the correct linker flags that are needed to incorporate this static library into my shared object?
I ran into the same problem. Assuming you are on Ubuntu < 15.04 (mine is 14.04 LTS), you need to disable PIE
./configure --disable-pie
and then the usual: make / make install etc.
Now you should be able to link the static libsodium.a to your .so. I got this from a recent discussion on github issue i raised here
I'm trying to link opencv libraries in eclipse for a c++ project.
When I link libraries that have one instance in the folder it seems to recognize it, but doesn't recognize when the libraries have few instances (perhaps the term instance isn't so accurate, i'm not quite sure what is the meaning of these different versions of libraries).
Therefore the problem doesn't seem to be related to misuse of lib or wrong path, as i have seen in other questions.
This is what I get when building the project:
12:33:17 **** Incremental Build of configuration Debug for project Test2 ****
make all
Building target: Test2
Invoking: GCC C++ Linker
g++ -L/usr/local/Matlab/2013b/bin/glnxa64 -o "Test2" ./BilateralFilter.o ./main.o ./stdafx.o -lopencv_core -lmwvision_res -lmwvision -lopencv_imgproc -lopencv_highgui
/usr/bin/ld: cannot find -lopencv_core
/usr/bin/ld: cannot find -lopencv_imgproc
/usr/bin/ld: cannot find -lopencv_highgui
collect2: error: ld returned 1 exit status
make: *** [Test2] Error 1
as you can see, the mwvision doesn't seem to have a problem, but the others do, and I think it has to do with them existing in multiple versions in the directory (but perhaps i'm wrong).
opencv_core, opencv_imgproc and opencv_highgui all have .so.2.4 and .so.2.4.2 versions.
These two links unfortunately did not provide an answer:
ld linkage problems: /usr/bin/ld: cannot find [libraryname]
/usr/bin/ld: cannot find shared library
Also I will mention that I have no use in Matlab, it's just where I found the libraries of opencv.
opencv_core, opencv_imgproc and opencv_highgui all have .so.2.4 and .so.2.4.2 versions.
If you read this description of external library versioning, you'll understand that the .so.2.4 is a runtime name of the library, and not its link-time name.
In order to link, you need .so (without the version suffix).
Having .so.2.4 but not .so usually comes about when you have e.g. libopencv-core package installed, but not libopencv-core-dev. The solution is to install the latter.
I have a very basic C++ project in code blocks that makes use of glfw.so and two other libraries that are compiled to .so files from another project, libHorde3D.so and libHorde3DUtils.so. The latter are placed in the project root folder, while glfw is somewhere in my /usr/lib (I think).
I have added the project folder to the linker and compiler search paths in code blocks. I have added the libHorde3D.so and libHorde3DUtils.so as well as glfw.so to the Link Libraries in the Linker Settings tab. I thought that this would be enough based on the previous similar questions here on stackoverflow.
However when I press build:
ld cannot find -lHorde3D.so
ld cannot find -lHorde3DUtils.so
ld cannot find -lglfw.so
My system is Arch Linux 64 and I am using GCC.
I also tried bopying libHorde3D.so and libHorde3DUtils.so in /usr/lib and /usr/lib64 with no success.
P.S. All search paths are copied across the Debug and Release target.
Say, if the library name is libmylibrary.so, then linker option to link against that library would look like -lmylibrary. Note that lib prefix and .so suffix are not there — they are added automatically by the linker. In your case it seems like you specified the wrong name. Try removing .so from it, that should solve the problem.
Here is a simple demonstration of how to trigger the failure by making a similar mistake:
$ echo 'int main() { return 0; }' > test.c
$ gcc -o test ./test.c -lc
$ gcc -o test ./test.c -lc.so
/usr/bin/ld: cannot find -lc.so
collect2: ld returned 1 exit status
$
The first command succeeds and the second one (with incorrect library name) fails.
You must not pass ".so". The linker options are
-lHorde3D -lHorde3DUtils -lglfw
This way the linker will search for "libHorde3D.so" etc. in the library path(s).