Where should I put .so files in Ubuntu. In other words, what is the standard/convention for this.
/usr/lib is the folder for Libraries for the binaries in /usr/bin/ and /usr/sbin/. /usr/local/lib is the tertiary structure for binaries specific to the machine.
Related
How does CMake's find_library handle so version numbers like in "libFOO.so.3.2"? Some libraries have symbolic links from libFOO.so to the right version, some do not.
Does CMake find a library without the symbolic link when I just use find_library(NAMES FOO)?
What should I do to help CMake figuring out the right library?
Assuming a linux distribution, the system package manager will generally provide runtime packages and development packages. If you have installed the development package for a library (e.g. libFOO-dev), it will generally include the following three files in your /usr/lib or /usr/local/lib
libFOO.so.3.2.0 (the versioned binary)
libFOO.so.3 (soname = symlink to versioned binary)
libFOO.so (namelink = symlink to soname)
The namelink has no version details in the file name. This will be used to find the library by linker command line option, e.g. -lFOO
You should use the namelink (e.g. FOO) in the find_library cmake command.
The linker will embed the soname file into your binary.
If you have multiple versions of the library installed, be sure to symlink the namelink file to the soname file that you want to use. This is really only an issue if you have multiple major versions of the same library installed. Within a major version, APIs should be backwards compatible.
In addition to #marksisson's answer:
In case you download an SDK as a zip archive with such symlinked .so files it may happen that the symlinks are broken. Instead of real symlinks you have small text files containing the names of the linked files. As a consequence the linker complains about an unrecognizable file format.
To fix that, just recreate the symlinks after unpacking the zip file.
My source tree includes several executables and shared libraries (dlls). I would like to change my cmakelists.txt files so that executables are installed in multiple destination folders on the installer's sytem.
Source Tree
Editor
Editor.cpp
CMakeLists.txt
Game
Game.cpp
CMakeLists.txt
SharedLib
SharedLib.cpp
CMakeLists.txt
Desired install directory structure
Editor/
MyEditor.exe
MySharedLib.dll
Game/
MyGame.exe
MySharedLib.dll
Currently I use a install(TARGET MySharedLib RUNTIME DESTINATION Editor) but I also need to install MySharedLib for a second time and into Game directory.
How can I achieve this?
It is possible to specify multiple install locations for a cmake target by calling install() multiple times (http://www.cmake.org/cmake/help/v3.2/command/install.html#installing-targets).
However this call can only take place in the cmakelists.txt file of the targets directory.
I'm writing a small library.
I'd like to build it as shared library and generate "MyLibraryConfig.cmake" file which then can be used by my other projects to find my library.
The only problem I have is to figure out the name/path to file which is used for linking under Windows - there are two files being generated: mylibrary.dll and mylibrary.dll.a.
So I'd like to generate MyLibraryConfig.cmake file with something like:
"set(MYLIBRARY_LIBRARIES /blah/blah/mylibrary.dll.a)"
so then MYLIBRARY_LIBRARIES can be used with target_link_libraries for my other projects.
How can I get name for this linkable file? I'd be nice if the solution was platform independed (returning .so wile on Linux and .dll.a on Windows)
thanks in advance
If you're planning on making your library available to your other projects without installing it then you want the CMake command export. For example:
export(TARGETS MyLib FILE ${CMAKE_SOURCE_DIR}/MyLibraryConfig.cmake)
This creates the file MyLibraryConfig.cmake in the same directory as your top-level CMakeLists.txt, and can just be included in other CMake projects.
If you're planning on installing your library, then you want to make use of install(EXPORT ...) instead:
install(TARGETS MyLib EXPORT MyLibraryConfig
RUNTIME DESTINATION bin
LIBRARY DESTINATION lib
ARCHIVE DESTINATION lib/static)
install(EXPORT MyLibraryConfig DESTINATION cmake)
This will install the file MyLibraryConfig.cmake to <install path>/cmake, and can then be included by other projects.
I'm using cmake and cpack to build my project and build packages. I'm creating a few executables in my project, let's call them EXE1 and EXE2.
When creating different versions of these executables, I want to name to reflect the version of the executable (let's say EXE1_1.0.0). I can change the name of the output for a target by doing set_target_properties.
However, now when doing an install, I want to do create a symlink to this versioned name of the executable, i.e. I want to have
the "versioned" executable installed in bin directory, i.e. EXE1_1.0.0
create a symlink to the "versioned" executable, i.e. create symlink EXE1, which points to EXE1_1.0.0
Can someone suggest me how to do this?
Second question is:
How to install configuration files /etc/MYPROJECT/ directory? What DESTINATION I need to use for configuration files, like I use bin for executables and lib for libraries? Is using an absolute path like /etc an acceptable practice with cmake?
I asked this question on cmake mailing list subsequently, and this is the response I received:
The validity of the answer will depend on which CMake version you use
and which set of platform you want to support.
Symlinks are not that portable
a) Creation may not be [currently] done portably but if you are
targeting Unix you can use cmake -E create_symlink to create one.
b) Depending on the CPack generator you use and CMake/CPack version
symlinks may be embedded in the package or not.
i.e. CPack pre 2.8.7 cannot create ZIP archive which contains
symlinks CPack 2.8.8 can do that now.
Then you can use an install(SCRIPT ... or install(CODE ...) to do that
at install time.
Another option if you are using RPM is to use package specific post
install script. cpack --help-variable
CPACK_RPM_POST_INSTALL_SCRIPT_FILE
this last solution will off course only work for CPack RPM.
For second question
You can use absolute destination path, they should be handled just
fine by CPack DEB and RPM, I don't know for other.
If your software should be installed on Windows this is won't work
with archive generator (ZIP, TGZ, etc...) and/or NSIS.
May be you can do something like:
if(UNIX AND NOT APPLE) set(CONFDEST "/etc/${CMAKE_PROJECT_NAME}")
else() set(CONFDEST "etc") endif()
install(FILES yourconffile DESTINATION ${CONFDEST})
How to build and install a .so module with autotools/libtool without .la and .a libraries
being also installed into --prefix path?
Currently i am using following Makefile.am:
lib_LTLIBRARIES = libCurlDownloader.la
libCurlDownloader_la_SOURCES = Curl.cpp
libCurlDownloader_la_LDFLAGS = -module -avoid-version
It works, but in addition to libCurlDownloader.so it also installs libCurlDownloader.la and libCurlDownloader.a, what is undesirable.
Update #1
It is possible to make .a not be generated, by using either
./configure --disable-static
or
AC_ENABLE_SHARED(yes)
AC_ENABLE_STATIC(no)
in configure.ac
But it is still the question how to make .la not being installed into installation --prefix while having .so installed.
Update #2
It is possible to remove .la files from installation --prefix using
install-exec-hook: find $(DESTDIR)$(libdir) -type f -name \*.la -delete
You should not necessarily delete the .la files. The .la files contains information that is used in two situations:
Statically linking against the built library. When statically linking (i.e., .a with -static), there is no information about the dependencies of the library being linked, so libtool can use the information in the .la file to create an appropriate ld command referencing all the necessary dependencies. This is often more important on an environment like MinGW where the linker requires the same library specified multiples in a particular order to resolve recursive dependencies. This is only a concern if one intends to build a static binary.
Dynamically loading the build library on some platforms (i.e., with lt_dlopen if using libltdl). Similarly, on certain platforms, dependencies of the compile module are not encoded in the binary, so the .la file is needed so that lt_dlopen will find and load the correct dependencies. On ELF platforms (including Linux) and PE platforms (i.e., Windows), the dependencies are store in the library, so lt_dlopen will work without the .la files. The MachO format on MacOS can require .la files when building bundles.
The Debian/Ubuntu packagers have decided to exclude .la files from their packages because the second reason isn't appropriate on Linux and they would prefer you didn't build static binaries in the first place. On other platforms, which libtool is designed to support, the .la files may be needed for linking or running the program.
I stumbled upon this question because it used the term "module", which in automake/libtool speak is the term for a plugin. I have a plugin system in Finit, so I build my plugins with '-module' to avoid creating .a files. But I still get the .la files installed, which really is not even applicable in the '-module' case.
I've yet to find a documented way to skip .la files for plugins, but here is how I do it:
AM_LDFLAGS = -module -avoid-version -shared
pkglib_LTLIBRARIES = alsa-utils.la bootmisc.la
install-exec-hook:
#(cd $(DESTDIR)$(pkglibdir) && $(RM) $(pkglib_LTLIBRARIES))
To be clear, in my use-case there is nobody going to "link" against my plugin .so's, so the .la files really are of no use.