I have to check that certain libraries (libm, libdl) are present in order to compile my library.
In my configure.ac template file, there is PKG_CHECK_MODULES macros and PKG_CHECK_LIB macros.
I don't understand which one to use and how?
The PKG_CHECK_MODULES seems the most global one because it checks if a whole library is present and PKG_CHECK_LIB checks only if one function is accessible… But when I do PKG_CHECK_MODULES([LIBM],[libm],[],[exit -1]), it exists and I don't understand why.
I think I'm misunderstanding some concepts. Maybe someone could lead me to good references.
PKG_CHECK_MODULES is for integrating with packages that have pkg-config metadata. This metadata is typically stored in a file called foo.pc (for package foo) in someplace like /usr/share/pkgconfig. This file will say where foo and its associated files (header files, libraries, executables, data, etc.) have actually been installed.
However, most packages don't use the pkg-config system, including the standard C library which is where libm and libdl are. So you'll need to test for them using AC_CHECK_LIB.
You seem to be confused, so I'll go on a bit of a tangent here:
Once upon a time, there was X11; there were many incompatible installations of X11. To write code that would compile against each variant, people would write crazy autoconf macros to try to figure out automatically what libraries to list before, what libraries to list after, and what extra flags were needed in between. (see AC_PATH_X, AC_PATH_XTRA).
Some people tried more sensible approaches, and wrote shell scripts to install along the libraries; so you would just call them and they would give you all the magic flags needed for that specific libraries. (see sdl-config, wx-config, freetype-config, motif-config, etc)
Then the folks from freedesktop.org decided it was a chore for everyone to maintain those scripts that did essentially the same thing, so they wrote a tool (pkg-config) that would work like all those *-config scripts, and would not require a shell to run (yay for Windows users). All the library authors need to do is to write the metadata in the *.pc files, and install them along the libraries.
Regarding autoconf, it has low-level ways to poke around the system to find out about the libraries: AC_CHECK_HEADERS, to see if the headers are present and usable, and AC_CHECK_LIB, to see if it's possible to link against them.
The pkg-config tool comes with convenience macros for autoconf, mainly PKG_CHECK_MODULES, which instead of poking around, it simply looks for the metadata the library might have installed.
Regarding libm, libdl, as ldav1s said, they are part of the system; some systems need explicit link against libm (which provides math functions) and/or libdl (which provides functions for dynamically loading shared objects). Often other tools, like gcc or libtool, take care of linking against them. Unfortunately they don't come with meta-data for pkg-config, so if you have to find them manually, you'll have to poke around with the old AC_CHECK_HEADERS and AC_CHECK_LIB macros to find them.
Related
I need to create a portable linux program that uses a lot of additional libraries defined from yum (CentOS).
It is forbidden to install new packages on portable machines. There are no necessary libraries there.
How to assemble my program and all packages into a single folder through the gcc compiler? When I move this folder to another machine, my program should start and run successfully.
My program is ONLY allowed to use dynamic libraries. Static libraries are STRICTLY prohibited.
When trying to replace rpath with /usr/lib64/ with my libraries that are stored in my directory, after transferring to another machine, additional libraries give an error (glibc version conflict).
This sounds like a doomed project, for anything non-trivial.
Static libraries are not the issue though. Since they're just collections of .o files, you can unpack them. You can then state that you have just linked object files. Stupid rules give stupid results.
I am ignoring software licensing here, though, but that seems implied by the question. You don't need a license for libraries installed via yum, since YOU aren't shipping them. But you absolutely need licenses when you are shipping these libraries in one form or another as part of your product. And given the stupid rules, (L)GPL is likely out of the question, so you will need to obtain commercial licenses for all 7 libraries.
I am reverse engineering someone's code and I came across a line like so in the CMake file
FIND_PATH(OPENSSL_INCLUDE_DIR openssl/ssl.h
/usr/local/opt/openssl/include
/usr/opt/openssl/include
/usr/local/include/openssl
/usr/include/openssl
/usr/local/include
/usr/include
)
INCLUDE_DIRECTORIES(${OPENSSL_INCLUDE_DIR})
FIND_LIBRARY(LIB_CRYPTO crypto PATHS
/usr/local/opt/openssl/lib
/usr/opt/openssl/lib
/usr/local/lib
/usr/local/openssl/lib
/usr/lib
/usr/lib/openssl
)
I come from a make background, so I would use something like LDFLAGS=$(shell pkg-config --cflags --libs openssl but I would never know what header file is being included.
It seems impractical/unfeasible to know every header file included in, for example, a large dlib project which links opencv and cuda libraries, so my question is this:
When/Why would you actually reference the header file by name?
CMake needs to support platforms where pkg-config is not available.
You are correct that the find mechanism is somewhat primitive. That is why CMake also offers more sophisticated options like config-file packages or even pkg-config support. The problem with all these approaches is that they require some king of external support. Package config scripts must be provided by the dependency you are trying to find and pkg-config must be available and configured properly on the platform you are trying to build on.
The various find_* commands have no such prerequisites. They simply try to find a file or directory the filesystem. That's what makes them the most powerful commands in a way, because you can always accept a hint provided by the user where to find the files (which the people in your example code did not do btw, so shame on them) and then the find can work its magic. But it's also the most inconvenient, as it's easy to mess up and tedious to use in practice.
So keep in mind that CMake's primary goal is to be portable. Don't shy away from whatever mechanisms your platform offers to make configuring the build more convenient, but also don't lock out people that are less fortunate and have to work on platforms where those mechanisms are not available.
I'm new to C++ and wonder if it is good practice to include a library by source code. If it is, what would be the best way to achieve this? Just copying in a subfolder and using include?
In my special case, I have written a small library and I'm going to use it on two different microprocessors. Compiling the library separately, copying all headers and using this "package" seems to be overkill for me.
Compiling the library separately is what should be done.
It's not that overkill either : you're just compiling the .o files for your library, then wrapping them in an archive and handling that archive around.
Normally libraries are used as libraries because it is much easier and comfortable that way. If you are using dynamic libraries (.dll or .so) things get even better because you can replace libraries on the fly and things should continue to work smoothly.
You decided to use code repositories instead of libraries which means probably more work for you. If you are happy this way that's OK, but just make sure you do not break any license, some lgpl packages (like Qt) clearly
require their libraries to be linked dynamically.
The best way to do this: hard to say but in your place I would probably use git and include the libraries as submodules.
Just #includeing source code is a bad idea since it means just to copy the code into your own, things can go wrong that way. For example if there is a static variable somewhere in the library code and the same named static variable in your code you will have a conflict.
Instead you should probably compile the library separately and link it, possibly the same way as you would do anyway (ie you build the library and then you link with that library). But the light weight alternative would be just to compile the additional C++ files and then link the object files together to an executable. Details on how you do that is compiler specific.
There's valid reasons for including the library source in this way, for example if your project needs to modify the library during development it would be easier to do so if the rebuilding of the library is done as a part of the build process of the project. With a well designed build process the library shouldn't have to be rebuilt unless there are actual changes to it.
The value of a library is in part that you link it more often than you compile it, leading to a net saving.
If you control all the source, then whatever build process works best for you is fine.
I agree with πάντα ῥεῖ but I'll also add that the reason it is bad practice is because the compiled library can be stored in your computer in a common location and used by tons of different programs, thereby reducing the amount of data your computer has to store, in memory as well as RAM(if more than one running program uses the same library). An example is openGL which is a library that many games use and is probably already in your system somewhere. If you use windows, software installers link up these libraries to their programs and add them if you don't have them. If you use linux, you will be notified if libraries are missing and prompted to install them. All of that aside, you can, technically use un-compiled libraries but that introduces a number of potential licensing problems as well as additional problems with THEIR dependencies.
By copying source code to other projects and "mixing" it with other source code will stop this library from being a "library". Later on you will be tempted to make a small change in one copy (for CPU) or fix a bug and forget to do the same in the other copy.
There might be additional consideration but you should try to keep the code in one place. Do not Repeat Yourself (DRY) is a very strong and fundamental principal of software engineering with many benefits.
I am learning C++ and, in order to do so, am writing a sample wxWidgets application.
However, none of the documentation I can find on the wxWidgets website tell me what library names to pass to the linker.
Now, apart from wxWidgets, is there a general rule of thumb or some other convention by which I should/would know, for any library, what the names of the object files are against which I am linking?
We have more of a "rule of ring finger", instead of a thumb
Generally, if you compile the library by hand, it will produce several library files (usually .a .lib or something similar, depending entirely on your compiler and your ./configure) these are produced (typically) because of a makefile's build script.
Now a makefile can be edited in any way the developer pleases, but there are some good conventions (there is, in fact, a standard) many follow- and there are tools to auto generate the make files for the library (see automake)
Makefiles are usually consistent
You can simply use the makefile to generate the files, and if it's compliant, the files will be placed in a particular folder (the lib folder I believe?) all queued up and ready to use!
Keep in mind, a library file is simply the implementation of your code in precompiled format, you could create a library yourself from your code quite easily using the ar tool. Because it is code, just like any other code, you don't necessarily want to include all of the library files for a given library. For instance with wxWidgets if you're not using rich text, you certainly don't want to waste the extra space in your end executable by including that library file. Later if you want to use it, you can add it to your project (just like adding a .cpp file)
Oh and also with wxWidgets, in their (fantastic) documentation, each module will say what header you need to include, and what library it is a part of.
Happiness
Libraries are amazing, magical, unicorns of happiness. Just try not to get too frustrated with them and they'll prance in the field of your imagination for the rest of your programming career!
After a bit more Googling, I found a page on the wxWidgets wiki which relates to the Code::Blocks IDE, but which also works for me. By adding the following to the linker options, it picks up all the necessary files to link:
`wx-config --libs`
(So that does not solve my "general rule" problem; for any library I am working with, I still have to find out what files to link against, but at least this solves the problem for wxWidgets).
The build instructions are different for each platform and so you need to refer to the platform-specific files such as docs/gtk/install.txt (which mentions wx-config) or docs/msw/install.txt to find them.
FWIW wxWidgets project would also definitely gratefully accept any patches to the main manual improving the organization of the docs.
I'm not new in C++ although I'm new in Linux. I'm using CMake to precompile a cross-platform game engine with some third-party components, but I have a lot of doubts about using libraries. My question is how to work with third-party libraries and where to put them. Apt installs libs in their official place (/usr/local, /usr/lib/ ..) but I develop in Windows using local libs that are in a folder in my project dir.
Also, I need a good tutorial to know the rules of how libraries work. For example: when trying to compile my project, luabind is asking for liblua.s0.1, but AFAIK there is no way to generate this library with the source provided by Lua (at least doing make, make install).
I know, this question is fuzzy but I haven't enough experience to be more concise.
Update: After reading some answers, a more concise question is the following. If I install all third-party libraries, how can I distribute my program? How do I manage dependencies without using a large readme?
Where to put libraries
The best solution is to use your Linux distribution's packaging system (apt-get, yum, or similar) to install libraries from distro-provided packages wherever possible.
If the distro's packaged libraries aren't of a recent enough version, or if you need some nonstandard build options, or if you need a library that your distro doesn't provide, then you can build and install it yourself. You have two main options for where to put the library:
/usr/local (libraries under /usr/local/lib, headers under /usr/local/include). This installs the libraries systemwide and is probably the simplest solution, since you should then be able to build against them without taking any extra steps. Do NOT install libraries directly under /usr, since that will interfere with your distro's packaging system.
Under your project directory, as you did under Windows. This has the advantages of not requiring root access and not making systemwide changes, but you'll have to update your project's include paths and library paths, and you'll have to put any shared library files someplace where the dynamic linker can find them (using LD_LIBRARY_PATH or ld.so.conf - see the link for more details).
How libraries work
See David A. Wheeler's excellent Programming Library HOWTO. I'd recommend reading that then posting any specific questions as new topics.
How to distribute your program
Traditionally, Unix / Linux programs do not include copies of their dependencies. It's instead up to the end user or developer to install those dependencies themselves. This can require a "large README," as you said, but it has a few advantages:
Development libraries can be installed, managed, and updated via the distro's package manager, instead of each source copy having its own set of libraries to track.
There's only one copy of any given library on a system, so there's only one place that needs updating if, for example, a security flaw is found. (For example, consider the chaos that resulted when zlib, a very widely used compression library, was found to have a security flaw, so every application that included an affected version needed to be updated.)
If your program is popular enough (and is open source or at least freely available), then package maintainers for various Linux distributions may want to package it and include it in their distro. Package maintainers really don't like bundled libraries. See, for example, Fedora's page on the topic.
If you're distributing your program to end users, you may want to consider offering a package (.dpkg or .rpm) that they could simply download and install without having to use source. Ideally, from the end user's perspective, the package would be added to distros' repositories (if it's open source or at least freely available) so that users can download it using their package managers (apt-get or yum). This can all get complicated, because of the large number of Linux distros out there, but a Debian/Ubuntu compatible .dpkg and a Red Hat/CentOS/Fedora-compatible .rpm should cover a good percentage of end users. Building packages isn't too hard, and there are good howtos online.
for the first part of your question regarding Windows: there's no real standard place for libraries/headers on Windows, so the easy solution is: create your own. Simply provide a single lib/ and include/ on your system and have all your projects use it (by setting the path in a cmake file that you include everywhere). Put all third party libs in there, for example:
your projects:
d:/projects/projectA
d:/projects/projectB
third party stuff:
d:/api/lib/lua.lib
d:/api/include/lua/....
(you can even use symlinks aka 'directory junctions' if you have different version)
and the corresponding cmake file:
include_directories( d:/api/include )
link_directories( d:/api/lib )
Okay, so this is one of the basic questions and while I myself might not come across very clear on this, here goes:
While building a project, your compiler will need to find the header files of the libraries. The headers must be in the include path.
after compilation is done, the linker will look for the library binaries (files.so or something like that). These must be in the Library path.
That's the basics.
If you have some specific libaries, you can add them to your own project-specific lib/ and include/ directories and add them to the include path and the library path respectively.
Adding these dirs to these paths can be done in many ways, depending upon how you are building the project. I'm sure there is something called LD_PATH involved in all this... But I don't really know the specifics involved with CMake.
A little googling can help you do the above with CMake.
Hope that helps,
jrh
If you are installing the libraries with a package manager, they will probably all end up in the right place. If not you can get the compiler to search for the by providing the an additional search path using the -L <path> flag. You should be able to pass this extra flag to CMake.
Incidentally the -I <path> can be used to add an extra directory to search for include files.