My goal is to link the libraries /usr/lib/libboinc_api.a and /usr/lib/libboinc.a through CMake.
So I use the examples given in the different FIND_XXXX modules and I try :
FIND_LIBRARY(BOINC_LIBRARY NAMES libboinc_api libboinc
DOC "The Boinc libraries")
MESSAGE(${BOINC_LIBRARY})
But CMake don't find anything.
So I try (with the extensions) :
FIND_LIBRARY(BOINC_LIBRARY NAMES libboinc_api.a libboinc.a
DOC "The Boinc libraries")
MESSAGE(${BOINC_LIBRARY})
and the message gives me /usr/lib/libboinc_api.a.
So my questions are :
1) Why I am forced to precise the extension (in the cmake FIND modules, there is no extension precised) and how to avoid that ?
2) How to link the two files ? (in the current situation, the message says that only the first one is found, but maybe I misunderstand that...)
Thank you very much.
There are several mistakes here: First, the arguments after NAMES will be considered alternative libraries to search for. So if it can't find libboinc_api, it will try libboinc before failing. So you should rather run FIND_LIBRARY twice, one for each library.
Second, you need to either specify the name of the library as it would be supplied to the linker's -l option, i.e instead of libboinc_api you should just say boinc_api, or it's full filename as you did in the second attempt.
In the case of your original attempt, cmake would try to find a liblibboinc_api.so, liblibboinc_api.a, failing that liblibboinc.so, and finally liblibboinc.a.
Try this:
FIND_LIBRARY(BOINC_LIBRARY_API NAMES boinc_api
DOC "The Boinc API library")
FIND_LIBRARY(BOINC_LIBRARY NAMES boinc
DOC "The Boinc library")
Possibly in the reverse order.
Related
How to get CMake to link an executable to an external shared library that is not build within the same CMake project?
Just doing target_link_libraries(GLBall ${CMAKE_BINARY_DIR}/res/mylib.so) gives the error
make[2]: *** No rule to make target `res/mylib.so', needed by `GLBall'. Stop.
make[1]: *** [CMakeFiles/GLBall.dir/all] Error 2
make: *** [all] Error 2
(GLBall is the executable)
after I copied the library into the binary dir bin/res.
I tried using find_library(RESULT mylib.so PATHS ${CMAKE_BINARY_DIR}/res)
Which fails with RESULT-NOTFOUND.
arrowdodger's answer is correct and preferred on many occasions. I would simply like to add an alternative to his answer:
You could add an "imported" library target, instead of a link-directory. Something like:
# Your-external "mylib", add GLOBAL if the imported library is located in directories above the current.
add_library( mylib SHARED IMPORTED )
# You can define two import-locations: one for debug and one for release.
set_target_properties( mylib PROPERTIES IMPORTED_LOCATION ${CMAKE_BINARY_DIR}/res/mylib.so )
And then link as if this library was built by your project:
TARGET_LINK_LIBRARIES(GLBall mylib)
Such an approach would give you a little more flexibility: Take a look at the add_library( IMPORTED) command and the many target-properties related to imported libraries.
I do not know if this will solve your problem with "updated versions of libs".
Set libraries search path first:
link_directories(${CMAKE_BINARY_DIR}/res)
And then just do
target_link_libraries(GLBall mylib)
I assume you want to link to a library called foo, its filename is usually something link foo.dll or libfoo.so.
1. Find the library
You have to find the library. This is a good idea, even if you know the path to your library. CMake will error out if the library vanished or got a new name. This helps to spot error early and to make it clear to the user (may yourself) what causes a problem.
To find a library foo and store the path in FOO_LIB use
find_library(FOO_LIB foo)
CMake will figure out itself how the actual file name is. It checks the usual places like /usr/lib, /usr/lib64 and the paths in PATH.
You already know the location of your library. Add it to the CMAKE_PREFIX_PATH when you call CMake, then CMake will look for your library in the passed paths, too.
Sometimes you need to add hints or path suffixes, see the documentation for details:
https://cmake.org/cmake/help/latest/command/find_library.html
2. Link the library
From 1. you have the full library name in FOO_LIB. You use this to link the library to your target GLBall as in
target_link_libraries(GLBall PRIVATE "${FOO_LIB}")
You should add PRIVATE, PUBLIC, or INTERFACE after the target, cf. the documentation:
https://cmake.org/cmake/help/latest/command/target_link_libraries.html
If you don't add one of these visibility specifiers, it will either behave like PRIVATE or PUBLIC, depending on the CMake version and the policies set.
3. Add includes (This step might be not mandatory.)
If you also want to include header files, use find_path similar to find_library and search for a header file. Then add the include directory with target_include_directories similar to target_link_libraries.
Documentation:
https://cmake.org/cmake/help/latest/command/find_path.html
and
https://cmake.org/cmake/help/latest/command/target_include_directories.html
If available for the external software, you can replace find_library and find_path by find_package.
Let's say you have an executable like:
add_executable(GLBall GLBall.cpp)
If the external library has headers, give the path to its include folder:
target_include_directories(GLBall PUBLIC "/path/to/include")
Add the library directory path:
target_link_directories(GLBall PUBLIC "/path/to/lib/directory")
Finally, link the library name
target_link_libraries(GLBall mylib)
Note that the prefix and extension of the library file are removed:
libmylib.a ➜ mylib
mylib.so ➜ mylib
One more alternative, in the case you are working with the Appstore, need "Entitlements" and as such need to link with an Apple-Framework.
For Entitlements to work (e.g. GameCenter) you need to have a "Link Binary with Libraries"-buildstep and then link with "GameKit.framework". CMake "injects" the libraries on a "low level" into the commandline, hence Xcode doesn't really know about it, and as such you will not get GameKit enabled in the Capabilities screen.
One way to use CMake and have a "Link with Binaries"-buildstep is to generate the xcodeproj with CMake, and then use 'sed' to 'search & replace' and add the GameKit in the way XCode likes it...
The script looks like this (for Xcode 6.3.1).
s#\/\* Begin PBXBuildFile section \*\/#\/\* Begin PBXBuildFile section \*\/\
26B12AA11C10544700A9A2BA \/\* GameKit.framework in Frameworks \*\/ = {isa = PBXBuildFile; fileRef = 26B12AA01C10544700A9A2BA \/\* GameKit.framework xxx\*\/; };#g
s#\/\* Begin PBXFileReference section \*\/#\/\* Begin PBXFileReference section \*\/\
26B12AA01C10544700A9A2BA \/\* GameKit.framework xxx\*\/ = {isa = PBXFileReference; lastKnownFileType = wrapper.framework; name = GameKit.framework; path = System\/Library\/Frameworks\/GameKit.framework; sourceTree = SDKROOT; };#g
s#\/\* End PBXFileReference section \*\/#\/\* End PBXFileReference section \*\/\
\
\/\* Begin PBXFrameworksBuildPhase section \*\/\
26B12A9F1C10543B00A9A2BA \/\* Frameworks \*\/ = {\
isa = PBXFrameworksBuildPhase;\
buildActionMask = 2147483647;\
files = (\
26B12AA11C10544700A9A2BA \/\* GameKit.framework in Frameworks xxx\*\/,\
);\
runOnlyForDeploymentPostprocessing = 0;\
};\
\/\* End PBXFrameworksBuildPhase section \*\/\
#g
s#\/\* CMake PostBuild Rules \*\/,#\/\* CMake PostBuild Rules \*\/,\
26B12A9F1C10543B00A9A2BA \/\* Frameworks xxx\*\/,#g
s#\/\* Products \*\/,#\/\* Products \*\/,\
26B12AA01C10544700A9A2BA \/\* GameKit.framework xxx\*\/,#g
save this to "gamecenter.sed" and then "apply" it like this ( it changes your xcodeproj! )
sed -i.pbxprojbak -f gamecenter.sed myproject.xcodeproj/project.pbxproj
You might have to change the script-commands to fit your need.
Warning: it's likely to break with different Xcode-version as the project-format could change, the (hardcoded) unique number might not really by unique - and generally the solutions by other people are better - so unless you need to Support the Appstore + Entitlements (and automated builds), don't do this.
This is a CMake bug, see http://cmake.org/Bug/view.php?id=14185 and http://gitlab.kitware.com/cmake/cmake/issues/14185
It has been a long time since the question was posted but I am leaving this one just for reference.
I have a blog post describing step-by-step almost what you (or anyone else) were trying to do.
Please check here: https://michae9.wordpress.com/2022/09/01/shared-lib-to-be-used-by-client-programs-with-cmake/
I have an existing .so library (libgit2), and I would like to use this within a C program (the build system is Scons). I read through the entirety of the Scons documentation for "Chapter 4. Building and Linking with Libraries", but there is no mention of how to use an existing .so library. The only mention of .so in the entirety of chapter 4 is on the first page, and it is only about Scons using a .so file for output. How do I use an existing compiled .so library in Scons?
If you are using an sconscript then you should add a LIBS= arguments and a LIBS_PATH=.
if you want to directly add it to the build line, use -L for lib path and -l to link a lib.
You can find further information here: https://scons.org/doc/0.97/HTML/scons-user/x628.html
With help from the SCons Discord server and other places, I've gotten farther than when I first posted this question. I haven't solved my specific problem of using .so libraries with GDNative, but I think I've figured out the SCons side.
As of me posting this question, the SConstruct file was able to compile working code if I didn't use libgit2 and instead just printed out the text. With only the header included, my test call to git_libgit2_version compiled but didn't run, as Godot said undefined symbol: git_libgit2_version.
First of all, you need to add the named parameter for LIBS to your env.SharedLibrary or env.Program line. The lib prefix and .so suffix seem to be added automatically, I still haven't figured out how to make it point to libgit2.so.1.0.1 (so for now I have the library copied and named as libgit2.so, but I would like to have it point to libgit2.so.1.0.1 eventually instead). Also, the SCons team suggested adding LIBPATH, but this doesn't seem to actually do anything.
library = env.SharedLibrary(target=env["target_path"] + env["target_name"] , source=sources, LIBS=['git2'])
Then, the SConstruct file needs to have this magic line:
env['STATIC_AND_SHARED_OBJECTS_ARE_THE_SAME'] = 1
With the above code, ldd will report not found, and Godot will say Error: libgit2.so.1.0: cannot open shared object file: No such file or directory (I have no idea why it's asking for .so.1.0 instead of the .so or .so.1.0.1 file, and yes I tried copying and naming as libgit2.so.1.0 and that doesn't change anything either).
I also added this, which was suggested by another GDNative user.
env.Append(LINKFLAGS=[
'-Wl,-rpath,addons/git_for_godot/gdnative/linuxbsd'
])
With all of the above code, this seems to allow ldd and Godot to find the library just fine with a relative path (when running ldd you have to be cd'd into the project folder). I can run the project fine without any errors, but the project crashes immediately after opening, with no error messages printed. If I comment out the call to git_libgit2_version but keep the header included, the file does compile and run. Any time I try to call anything from libgit2 it causes Godot to crash without printing any errors. At this point I'm stuck and I don't know what I'm doing wrong.
I did try adding libgit2 to the Dependencies section of the .gdnlib file, but this doesn't seem to affect anything. Another thing I tried which didn't work is this line (+ variants on the extension) which append to the sources list passed as the named source parameter. I'll post it here for completeness, but for the moment I have this line commented out because it doesn't work:
sources.append(File("project/addons/git_for_godot/gdnative/linuxbsd/libgit2.so"))
EDIT: NEVERMIND - I had already successfully fixed this problem by putting a copy of the header where the compiler would find it. However, other build errors in cmake-gui kept referring me to the old error log file with the old build error, making me falsely believe I had not solved the problem.
I will close this question once the seven day bounty period is expired.
I am attempting to create a Windows port of a Linux library that uses pthreads via pthreads-win32, but I am having issues telling CMAKE where to locate pthreads.h. Does anyone know how to direct CMAKE to look to a specific location for pthreads.h? And also for the library file?
Alternately, is there some sort of magical global include directory I could use?
For example , in CMakeLists.txt , you can use INCLUDE_DIRECTORIES to include the path .
INCLUDE_DIRECTORIES([AFTER|BEFORE] [SYSTEM] dir1 dir2 ...)
and you can add the link path of pthread.h with this when you want to link the library :
LINK_DIRECTORIES(directory1 directory2 ...)
TARGET_LINK_LIBRARIES(target library1<debug | optimized> library2...)
In here , it say that you can link with libwinpthread.a
I found a pacman project in github where a file conf.c includes a header file #include "ini.h" where ini.h contains only a single line (i.e no #include statement):
//ini.h
../common/ini.c
I have never seen anyone doing this before! It seems a bit hackish/rough around the edges. My questions are:
Is this legal C?
Is it portable?
Is it recommended?
I would have assumed the answer should be no for all these questions, but I may be learning something new...
edit
From the answers, I see its a Linux symlink. I guess that this means it is not portable to Windows, and would also make it more difficult to read outside a unix environment. I would also imagine that using relative paths (or include directories) instead of symlinks would be a better practice in cases like this for reasons mentioned above...
src/pacman/ini.h is a symbolic link according to the site.
Symbolic link has an information of where the target file is (path name), and I guess it is what is displayed on the site.
The OS will redirect access to that ini.h to ../common/ini.h, which is a normal C code.
I don't see any reason why not. The include statement indicates the compiler to replace that line with the whatever is in the included file
I am trying to build a shared object for Android using ndk-build command, the source compiles fine but then I get this error:
make (e=206): The filename or extension is too long.
If any body can tell me what causes this problem and how to fix it.
Thanks.
You hit the Windows command length limit. You should use some static libraries as a workaround. Typically, people compile branches of their source tree with separate Android.mk files that end with include $(BUILD_STATIC_LIBRARY), and then list these as $(LOCAL_STATIC_LIBRARIES) in the "main" jni/Android.mk that ends with include $(BUILD_SHARED_LIBRARY). Your ndk-build will load this "main" makefile, so it should include (explicitly or using some nesting approach) all the static library makefiles.
But this is only a convenience. You can achieve the same result if you use single jni/Android.mk file as you have now.
You may also find it easier to list the static libraries as $(LOCAL_WHOLE_STATIC_LIBRARIES) - this way you guarantee that the order of listing these libraries will not cause linking problems.
You can add this to Application.mk
APP_SHORT_COMMANDs :=true
This worked for me.
Maybe as a workaround, you can try to subst the directory "D:\MyFiles\Android\Datte\obj\local\armeabi\objs\ngspice\spicelib" for a drive letter, using:
subst X: "D:\MyFiles\Android\Datte\obj\local\armeabi\objs\ngspice\spicelib"
This could save some space and generate a smaller command line. However, it might not solve your problem, depending on the Windows command length limit, as Alex Cohn answered. Besides, you'll have to change your makefile and change, for example,
D:/MyFiles/Android/Datte//obj/local/armeabi/objs/ngspice/spicelib\parser\inp2y.o
for
X:\parser\inp2y.o