Simple installation from source on Linux - c++

I'm trying to figure out a simplified way for installing C and C++ code
and libraries built from them, primarily for Linux. I think GNU Autotools, CMake, etc. would be overkill for what I'm trying to do.
An example: I've written some code which, when 'make' is run, builds to
create a library 'example.a'. (I'm going with static linking thus far.
Shared libraries will introduce still more issues; I'll crawl before I walk.) Use of the functions requires including 'example1.h', 'example2.h', etc.
With Autotools, one would run 'make install' or 'sudo make install' to
copy example.a to /usr/local/lib and the include files to /usr/local/include.
If executables had been built, those would get copied to /usr/local/bin.
I've tried adding the following lines to my makefile:
install:
cp example.a /usr/local/lib
cp example1.h /usr/local/include
cp example2.h /usr/local/include
cp example /usr/local/bin
This seems to work, mostly. Other projects are then able to "see"
the .h files and build correctly. But the .a file is not found; the only
way to get it to be linked is to explicitly give the path as
/usr/local/lib/example.a. (Though gcc insists it's looking for libraries
in that path.) So:
Question 1: Should my user-built libraries be put in /usr/local/lib? Or am
I using the wrong directory?
Now, my next problem: this has to be done with 'sudo make install'.
I'm thinking that for some projects of this ilk, where only one user will
be making use of the code in question, the libraries should go someplace
such as $HOME/lib, include files to $HOME/include, executables to
$HOME/bin.
Question 2: Is there a "standard" way to install includes/libraries for
just the current user, rather than doing so for all users? (Thus avoiding
the need for root use, and I'd think it would be a "cleaner" system if only
the user using the program had to deal with these files.)

You should probably use install to copy with explicit permissions. example.a probably isn't being found because it doesn't start with lib (a stupid requirement, I know).
Putting your lib, include, and bin under $HOME/.local is probably the closest thing to a per-user standard setup.
Edit:
I just tested it and it /usr/local/lib works fine for me:
foo.c
#include <stdio.h>
void foo() { puts("foo"); }
Compile and install:
gcc -c foo.c
ar crs libfoo.a foo.o
install -m 0755 /usr/local/lib #0644 should do too
In a different directory:
main.c
void foo(void);
int main() { foo(); return 0; }
Compile, link, and run:
gcc main.c -lfoo
./a.out

Related

CMake include_directories isn't using one directory, but using all others around it

I'm trying to use conda to manage several dependencies for a c++ library I'm building (I was previously using git submodules in my project's external/ dir which worked fine, but for a number of reasons I wanted to migrate to conda).
The libraries I need to use are tbb, zstd, and cspice. I've verified they are all installed correctly by conda, and are in my environment (named vira_env). The headers are very clearly in ~/mamba_envs/vira_env/include/.
However when I add include_directories(${CMAKE_INSTALL_PREFIX}/include) to my root CMakeLists.txt and run cmake using -DCMAKE_INSTALL_PREFIX=${CONDA_PREFIX}, it fails to find any of the headers.
Running make VERBOSE=1 reveals that g++ has no -I argument to include the ~/mamba_envs/vira_env/include/ directory. Which makes sense, as it is failing to find the headers that are there.
However, if I use include_directories(${CMAKE_INSTALL_PREFIX}) and rerun make VERBOSE=1, or it clearly shows that g++ has a -I /home/cgnam/mamba_envs/vira_env/.
Similarly, if I use include_directories(${CMAKE_INSTALL_PREFIX}/include/oneapi) it shows g++ has a -I /home/cgnam/mamba_envs/vira_env/include/oneapi. (oneapi is the directory where the tbb headers are placed).
So include_directories() will happily use either the conda environment root, or even one of the directories inside the conda environment's include/ directory... but it will just completely ignore the include/ directory itself.
EDIT
As discovered in one of my comments below, printing CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES shows /home/cgnam/mamba_envs/vira_env/include. Which explains why my include_directories() is not having any effect on the g++ call by make, since it believes that the compiler should be looking in that directory already.
make VERBOSE=1is showing that the compiler being used is: /home/cgnam/mamba_envs/vira_env/bin/x86_64-conda-linux-gnu-c++. However using which g++ is showing ~/mamba_envs/vira_env/bin/g++. Further, which ld returns: ~/mamba_envs/vira_env/bin/ld.
If I use ld --verbose | grep SEARCH_DIR, it does not show /home/cgnam/mamba_envs/vira_env/include. Neither does ~/mamba_envs/vira_env/bin/x86_64-conda-linux-gnu-ld --verbose | grep SEARCH_DIR.

libSDL2-2.0.so.0: cannot open shared object file

I'm trying to build the SDL library from the source code. I've downloaded the compressed file (i.e. SDL2-2.0.3.tar.gz) and extracted it. I don't want to install the files in /usr/local. According to this link, I need to change the configure
The last command says "sudo" so we can write it to /usr/local (by
default). You can change this to a different location with the
--prefix option to the configure script. In fact, there are a LOT of good options you can use with configure! Be sure to check out its
--help option for details.
This is what I've done.
mkdir build
cd build
../configure
make
sudo make install
In install folder that I've created are the following files
share
lib
include
bin
Now I would like to run the test files. I've picked this testatomic.c and this is the command line
gcc testatomic.c -o test -I/home/xxxx/Desktop/SDL2-2.0.3/install/include/SDL2 -L/home/xxxx/Desktop/SDL2-2.0.3/install/lib -lSDL2 -lSDL2main
I get this error
error while loading shared libraries: libSDL2-2.0.so.0: cannot open shared object file: No such file or directory
In lib, these are the files
Where is the shared object file?
You're getting error when running resulting program because system's dynamic linker cannot find required library. Program requires libSDL2-2.0.so.0, linker looks for it in system-defined directories (/lib, /usr/lib, ..., - defined in /etc/ld.so.conf), but finds none - hence an error.
To inform linker where you want it to look for libraries, you can define LD_LIBRARY_PATH environment variable, e.g. in your case:
export LD_LIBRARY_PATH="$HOME/Desktop/SDL2-2.0.3/install/lib"
./test
Other ways is installing libraries in standard location, defining LD_LIBRARY_PATH in your .bashrc (or whatever shell you use), or using rpath, e.g. adding -Wl,-rpath=$HOME/Desktop/SDL2-2.0.3/install/lib at the end of your compilation line.
I was able to fix this problem with:
sudo apt install libsdl2-dev
I too had:
./01_hello_SDL: error while loading shared libraries: libSDL2-2.0.so.0: cannot open shared object file: No such file or directory
as a result of compiling the first C++ program (using the SDL headers) as part of the Lazy Foo tutorial. I found out that libSDL2-2.0.so.0 was just using the find command in the GUI. It turned out to be in /usr/local/lib
Then in terminal I typed:
export LD_LIBRARY_PATH="/usr/local/lib"
I checked the value of LD_LIBRARY_PATH using:
echo $LD_LIBRARY_PATH
I recompiled (don't know if that was necessary) and voila, it worked.

Libusb and how to use its packages in Ubuntu

I have installed libusb by using the following command. I am not sure if it was right or not and the command was
sudo apt-get install libusb-dev
Once I have installed (and I am not sure if it has installed or not because I am a novice user of Ubuntu), I want to know how would I use the library, because I write some sample code which uses <libusb.h>, but when I compile that C++ file using
g++ test_libusb.cpp
that throws the following error,
test_libusb.cpp:2:20: fatal error: libusb.h: No such file or directory compilation terminated.
I am clueless what to do. I can't find any source on the Internet to get to the bottom of this...
I want to know two things here:
How do I add the libusb library in C/C++ so I can use <libusb.h>?
What would some sample code be? Only a few lines to see if libusb is working...
Try including it like so:
#include <libusb-1.0/libusb.h>
and then compile it like so:
g++ main.cpp -o main -lusb-1.0
Have a look at http://packages.debian.org/wheezy/i386/libusb-dev/filelist: The file you want to include is usb.h. Also, you'll have to tell the compiler where it can find the compiled library functions: Add -lusb to the compiler command line to make it load libusb.so.
Actually at least in Debian 7.4 (wheezy), and probably in Ubuntu also, there are two distinct libusb packages: libusb-dev (0.1.12-20+nmu1) and libusb-1.0-0-dev (1.0.11-1). Confusingly, they can both be installed concurrently and provide header files in different locations:
$ dpkg -L libusb-dev|grep /usr/include
/usr/include
/usr/include/usb.h
$ dpkg -L libusb-1.0-0-dev|grep /usr/include
/usr/include
/usr/include/libusb-1.0
/usr/include/libusb-1.0/libusb.h
Try #include <usb.h>. The "lib" is part of the Linux naming convention, i.e. library "foo" has header foo.h and is called libfoo-dev in the Debian package structure, and linked as -lfoo, and the compiled library files are called libfoo.a and libfoo.so.

Cannot open shared object file

I am trying to compile one of the projects found here
USB-I2C/SPI/GPIO Interface Adapter.
I downloaded the i2c_bridge-0.0.1-rc2.tgz package. I installed libusb and that seemed to go well with no issues. I go into the i2c_bridge-0.0.1-rc2/ directory and make. That compiles. I move into the i2c_bridge-0.0.1-rc2/i2c folder and make. It compiles and gives me ./i2c. However, when I run it, it says error while loading shared libraries: libi2cbrdg.so: cannot open shared object file: No such file or directory
The makefile in i2c_bridge-0.0.1-rc2/i2c has the library directory as ../. The libi2cbrdg.so is in this directory (i2c_bridge-0.0.1-rc2). I also copied the file to /usr/local/lib. An ls of the i2c_bridge-0.0.1-rc2/ directory is
i2c i2cbrdg.d i2cbrdg.o libi2cbrdg.a Makefile tests
i2cbrdg.c i2cbrdg.h INSTALL libi2cbrdg.so README u2c4all.sh
(That i2c is a directory)
If I sudo ./i2c, it still gives me the problem.
I had to take away the -Werror and -noWdecrepated (spelling?) options in all the makefiles to get them to compile, but that shouldn't affect this should it?
What else is necessary for it to find the .so file? If anyone can help me find out what is wrong I would be very grateful. If more information is needed I can post it.
You have to distinguish between finding so's at compile-time and at run-time. The -L flag you give at compile-time has nothing to do with localizing the library at run-time. This is rather done via a number of variables and some paths embedded in the library.
The best hot-fix for this problem is often setting LD_LIBRARY_PATH to the directory with the .so file, e.g.:
$ LD_LIBRARY_PATH=.. ./i2c
For a long-term solution, you need to either have a close look at the whole LD system with rpath and runpath, or use libtool (which solves these issues for your portably).
Copying a file to /usr/local/lib is often insufficient because ld caches the available libraries, so you need to re-run ldconfig (as root) after you copied a library to /usr/local/lib.
If you are building the code from source that needs the the library, you can put the path that the library is in in the environment variable LD_RUN_PATH before building, and the linker will save that path into the binary, so that it will automatically be looked for in the right place at runtime.
Linux specific: Alternately, put the library in /lib, /usr/lib, or some other path referenced in your /etc/ld.so.conf or its imported config fragments, and then all you need to do is run /sbin/ldconfig to refresh ld.so (the dynamic linker)'s cache of libraries.
This works for my issue,hope will help anyone.
gcc test.c -Wl,-rpath /usr/local/lib -lfcgi -o test.fcg
And -Wl,-rpath option is the key trick.

How to build a shared library (.so) without hardcoded full dependency paths?

I need to build two 3rd party shared libraries, so their .so files will be reused by other projects. However, after build one of these libraries contains hardcoded path to another. This path is invalid on other machines and causes linker warnings. How can I prevent the full path from being embedded in the resulting .so files?
Details:
First library source: ~/dev/A
Second library source: ~/dev/B
Both of them have configure script to generate make files. Library B depends on A. So, first I build A:
$ ~/dev/A/configure --prefix=~/dev/A-install
$ make && make install
Then I build B:
$ ~/dev/B/configure --prefix=~/dev/B-install --with-A=~/dev/A-install
$ make && make install
Then I want to upload the contents of ~/dev/A-install and ~/dev/B-install to our file server, so other teams and build machines can use the binaries. But they get linker warnings when they try to use B:
/usr/bin/ld: warning: libA.so.2, needed by /.../deps/B/lib/libB.so, not found (try using -rpath or -rpath-link)
When I run ldd libB.so it gives:
...
libA.so.2 => /home/alex/dev/A-install/lib/libA.so.2
Obviously this path exists only on my machine and cannot be found on other machines.
How can I remove full hardcoded path from libB.so?
Thanks.
You have to use --prefix value that will be valid in the runtime environment for both packages!
Than you override prefix or DESTDIR (prefix replaces the prefix, DESTDIR is prepended to it, but works more reliably) on the make command-line when installing. Like:
~/dev/A$ ./configure
~/dev/A$ make
~/dev/A$ make install prefix=~/dev/A-install
~/dev/B$ ./configure --with-A=~/dev/A-install
~/dev/B$ make
~/dev/B$ make install prefix=~/dev/B-install
or (which is preferred and is how all package-building tools use it):
~/dev/A$ ./configure
~/dev/A$ make
~/dev/A$ make install DESTDIR=~/dev/A-install
~/dev/B$ ./configure --with-A=~/dev/A-install/usr/local
~/dev/B$ make
~/dev/B$ make install prefix=~/dev/B-install
because this way you are installing to ~/dev/A-install/$prefix, so with default prefix ~/dev/A-install/usr/local. The advantage of this later option is, that if you redefine some specific installation paths without refering to prefix (say --sysconfdir=/etc), DESTDIR will still get prepended to it, while it won't be affected by prefix.
-Wl,-rpath,~/deps/A/lib:~/deps/B/lib:~/dev/MyApp/bin
This linker option is responsible for saving the path inside the library. You need somehow to remove this.
See with ./configure --help if there's some option that could influence this. Another option is to edit manually the makefile and remove this option.
== edit2 ==
One more thing
-L~/deps/A/lib -L~/deps/B/lib ~/deps/A/lib/libA.so ~/deps/B/lib/libB.so
If libA.so and libB.so don't have SONAME, linking them like "~/deps/A/lib/libA.so" will also cause saving the path. Soname is set using -Wl,-soname,<soname> linker option when building shared library.
If soname is set in the shared library, linking it using "~/deps/A/lib/libA.so" form is ok.
Like Jan mentioned in the comments, the better way is using "-Llibrary/path -llibrary_name" without rpath.
-L~/deps/A/lib -L~/deps/B/lib -lA -lB
When I run ldd libB.so it gives:
libA.so.2 => /home/alex/dev/A-install/lib/libA.so.2
The low-level solution to this problem is to use the option "-soname=libA.so" when you link the libA.so library. By having SONAME defined for a shared object, the linker will not embed absolute paths when linking against that shared object.
The OP is using "configure", so this isn't an easy solution to implement unless he is willing to go into the bowels of the Makefile generated by the configure script.
Shared libraries and executables have a list of directories to look for shared libraries, in addition to the list in the operating system's configuration. RPATH is used to add shared library search paths, used at runtime.
If you want a relative path to be used in RPATH, there is a special syntax that most Linux/UNIX (but not AIX) systems support - $ORIGIN or ${ORIGIN}.
$ORIGIN will expand at runtime to the directory where the binary resides - either the library or executable.
So if you put executable binaries in prefix/bin/ and shared libraries in prefix/lib/ you can add an entry to RPATH like ${ORIGIN}/../lib and this will expand at runtime to prefix/bin/../lib/
It's often a little trick to get the syntax correct in a Makefile, because you have to escape the $ in ORIGIN so it will not be expanded. It's typical to do this in a Makefile:
g++ -Wl,-rpath=\$${ORIGIN}/../lib
Both Make and the shell will want to look in your environment for a variable called ORIGIN - so it needs to be double-escaped.
I just got caught out thinking I had the same problem.
None of the above answers helped me.
Whenever I tried
ldd libB.so
I would get in the output:
libA.so.1 => /home/me/localpath/lib/libA.so.1.0
and so I thought I had a hardcoded path. Turns out that I had forgotten I had LD_LIBRARY_PATH set for local testing. Clearing LD_LIBRARY_PATH meant that ldd found the correct installed library in /usr/lib/
Perhaps using the -rpath and -soname options to ld could help (assuming a binutils or binutils.gold package for ld on a recent Linux system)?