When installing libraries for C++ on Ubuntu 15.10 via the terminal, I notice that a lot of them are named along the lines of libexample-dev or maybe libexample2. When naming libraries for Linux programming, how should I go about doing so conventionally? Also what is meant by dev at the end and what are the other things that could follow the dash after the name?
A library is not the same as the Debian/Ubuntu package providing it.
The libfoo-dev (so called development) package often provides some header files and the static library (needed to build source programs using that library).
The libfoo package is providing the shared libraries (needed by other programs and packages to run).
Often the libfoo-dev package is depending upon its libfoo package.
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.
What is the utility of devel packages like "libgtk+-devel" or "python-devel" etc.? Do they contain source of the library? How is it different from non-devel packages like libgtk+?
The *-devel packages (usually called *-dev in Debian-based distributions) are usually all the files necessary to compile code against a given library.
For running an application using the library libfoo only the actualy shared library file (*.so.*, for example libfoo.so.1.0) are needed (plus possibly some data files and some version-specific symlinks).
When you actually want to compile a C application that uses that library you'll need the header files (*.h, for example foo.h) that describe the interface of that application as well as a version-less symlink to the shared library (*.so, for example libfoo.so -> libfoo.so.1.0). Those are usually bundled in the *-devel packages.
Sometimes the *-devel packages also include statically compiled versions of the libraries (*.a, for example libfoo.a) in case you want to build a complete stand-alone application that doesn't depend on dynamic libraries at all.
Other languages (such as Java, Python, ...) use a different way of noting the API of a library (effectively including all the necessary information in the actual library) and thus usually need no separate *-devel packages (except maybe for documentation and additional tools).
They usually contain necessary headers and libraries. For example, python-devel will provide the Python headers and libraries that you need if you want to embed the Python interpreter in your own application. Some additional tools and documentation are included, too (e.g. a developer manual or code examples).
I'm trying to do a Linux release for a piece of Qt software, but I'm a clueless Linux newbie. I've built my application with the Qt libraries statically linked, and made .deb and .rpm packages, but when I test them I get warnings about missing libraries on some distributions. For example, my .deb version runs fine on Debian and Ubuntu, but it doesn't start on Linux Mint KDE due to missing libraries. Running ldd I find there are four missing libraries:
libpng16.so.16 => not found
libicui18n.so.57 => not found
libicuuc.so.57 => not found
libicudata.so.57 => not found
Clearly I need to somehow ensure all the necessary library are present, however the list of libraries required seems to vary. For example Linux Mint Cinnamon lists 33 libraries, while Ubuntu Unity lists 34 (libpng12.so.0 is the extra one). I also assume that some of those libraries are standard Linux libraries that would come with all distributions so I wouldn't need to include them.
I don't really know what I'm doing, so a few questions:
What is the best way to determine the list of libraries I need to include with my .deb and .rpm packages? If ldd is the best option, do I need to include all the listed libraries or are there some that are bundled as standard with all Debian/rpm distributions?
What is the best way to to include those libraries? Do you include them in the package or specify them in the dependency list?
Any other general advice would be appreciated because I'm not really sure I'm going about this the right way.
Thanks.
Don't think about library dependencies; think about package dependencies.
When you create your (deb, rpm) package, you can list other packages that it depends on. Figure out which package has your desired library in it, and add that package as a dependency.
Then, when the user installs your package, their package manager will also, if it needs to, install the packages that it depends on. Presto: you have the libraries you need.
We have been porting our Java API to C++, and creating a library file (.a file) for Linux. Our API has dependency on the boost framework and also on log4cxx. (We discussed with the first user for this, and they are okay with those dependencies).
When I compile a sample application which uses our library file, it is linking against .so files for the dependencies (libboost_system.so, libboost_thread.so, and liblog4cxx.so). When the application runs, it needs to find the specific versioned file names for each of those .so files, e.g. liblog4cxx.so.10.
If the user is using a newer version of boost (for example), would s/he be able to link against their local version and run with that newer version (assuming bacwards compatibility)? Is there some other way to deal with versions/dependencies like these (i.e. do you try to link in the external referenced libraries to your own library)?
Yes, the program can link to newer libraries with a compatible interface. The numbers in the filename encode the library Application Binary Interface (ABI).
FreeBSD's handbook has more information about library versioning. The basic rules are:
Start from 1.0
If there is a change that is backwards compatible, bump minor number (note that ELF systems ignore the minor number)
If there is an incompatible change, bump major number
The linker will sort out the details to use the newest library version with a compatible interface. There is also more information available here on stackoverflow.
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.