I'm trying to use the EPEL package boost169-devel on CentOS 8. I'm trying to build my C++ source code with the boost library version 1.69 from this package.
I see that that package has header & .so files in non-standard locations, /usr/include/boost169 instead of /usr/include for headers and /usr/lib64/boost169/ instead of /usr/lib64 for .so.
I know I can hack my build files to make it work -- munge my gcc's -I to have /usr/include/boost169 in front and add a -L /usr/lib64/boost169 in the beginning. But my build files are also used to build on other distros, so I'm looking for a cleaner way that does not involve introducing a lot more complexity to my build system. E.g. for gcc-toolset-9, which also installs things in non-standard locations, one can use scl enable gcc-toolset-9 bash to have the paths setup properly without caring about the implementation details. Is there a prescribed way or cleaner way for dealing with the non-standard location of boost169-devel than manually munging -I and -L?
Related
I want to use openssl library in my NaCl module. Luckily it is ported already as in https://code.google.com/p/naclports/. However, its kind of pity but I don't know how to add the library to the toolchain. I did as instructed in the Readme file:
...nacl_sdk/pepper_33/naclports/src$ python build_tools/naclports.py install openssl
Already installed 'openssl' [x86_64/newlib]
And then I tried to compile this simple C code, and the compiler complaint some errors which are because of linking problem with openssl/evp.h.
This is my Makefile: link. Please let me know how to make it run.
NaCl actually consists of several different toolchains. naclports will build and install a given library to just one of them at time. The libraries and headers get installed directly into the toolchain so there is no need to -L or -I on the command line.
In this case you have built and installed the x86_64 newlib version of openssl. This means that you should be able to build the x86_64 newlib version of your app (add TOOLCHAIN=newlib NACL_ARCH=x86_64 to your make call).
To build all the other versions of openssh you can use the "make_all.sh" script at the top level of naclports (e.g. ./make_all.sh openssl).
Build naclports. Look in naclports/README.rst for instructions.
I'm building my program on my computer, on which libtiff.so -> libtiff.so.5.
And then pushing the builds on another machine on which libtiff.so -> libtiff.so.4.
At runtime, my program exists : « error while loading shared libraries: libtiff.so.5: cannot open shared object file: No such file or directory ».
I cannot upgrade the other machine, and I would like to avoid compiling on a virtual machine (with the same linux version than the executing machine). Therefore, I would like to force the compiler to use the libtiff.so.4 instead of libtiff.so.5.
I have libtiff.so.4 installed on my computer (as well as libtiff.so.5). How can I force the linkage with this version instead of the newer version. I thought about moving the libtiff.so -> libtiff.so.4, but I'm afraid of breaking my system if it needs the latest version (apt-get purge libtiff5 gives an error because some other package needs it).
Is it possible to link with an older (installed) version of a library? If yes, how?
And is it harmfull to change the symbolic link of libtiff.so to the older version? If not, will it solve my issue?
You can use this syntax to link to a specific version of a library:
gcc [other options] -l:libtiff.so.4
You do not need to specify a path; the usual directories are searched in order to find the library.
Note: as Michael Wild mentioned, you should have the header files for that version installed instead of the newest ones.
As others have mentioned, you can force the linker by specifying the full versioned name, or even the absolute path.
However, I would strongly advice against doing so. The problem is, that the installed headers correspond to the newer version of the library. If there have been API/ABI-breaking changes between these library versions, the program might work, crash intermittently, or if you're lucky, not work at all.
Instead you should temporarily install the development package that corresponds to the libtiff.so.4 library. If on Debian/Ubuntu or similar, this would be the libtiff4-dev package.
Specify the full path to the .so: instead of -ltiff pass /lib64/libtiff.so.4 to the linker.
You see that error when application is running. So you can either stop your application and then exrract your library tar file. Or, force to link the lib file to the newer version after you extract. In second case, you will use something like:
ln -fs libversionname libfile
Example:
ln -fs libomyapp.1.1.3 libomyapp.lib
This links your libomyapp.lib to the version specified. This can be your older vsersion or your newer version.
But as said, best way to work is to bring down your application to properly match to the expected lib functionality to work without errors or issues.
So I recently got fed up with Windows and installed Linux Mint. I am trying to get a project to build I have in Code::Blocks. I have installed Code::Blocks but I need glew(as well as a few other libraries). I found it in the software manager and installed it. I've managed to locate and include the header files. But I feel like the next step should be relatively straightforward and all over the internet but (perhaps due to lack of proper terminology) I have been as of yet unable to locate an answer.
Do I need to locate the files on my system and link to each library manually? This is what I did on windows but I just downloaded the binaries and knew where they were. I found one library from the software manager and linked to it manually but it just feels like I'm doing it the wrong way. Since it's "installed" on the system is there some quick way to link?
You should use two flags for linker '-l' and '-L'. You can set these flags somewhere in project properties.
The first one '-l' tells linker to link with particular library. For example glew, probably in /usr/lib is a file named libglew.so, when you link your program with '-lglew' flag, it will link it with glew library. Linker looks for libraries in few standard places: /usr/lib, /usr/local/lib and few extra. If you have your libs in nonstandard place, use '-L' flag to point these dirs.
Many linux distributions provide two kinds of packages with libraries, regular ones just with runtime, and devel ones (usually prefixed or suffixed with dev or devel) with header files and development version of libraries.
use build systems, Luke!
the typical way to develop/build software in *nix world is 3 steps:
configure stage -- before building smth you have to realize in what environment you are going to build your software... is everything that required is installed... it wouldn't be good if at compile stage (after few hours of compilation) you (or user who build your soft) got an error: unable to #include the 'xxx.h'. the most popular build systems are: cmake, my favorite after autotools. yout may try also scons or maybe crazy (b)jam...
compile stage -- usually just make all
install stage -- deploy just built software into the system. or other way: build packages for target distro (.deb/.rpm/&etc)
at configuration stage using test scripts (don't worry there are plenty of them for various use cases) you can find all required headers/libraries/programs/compiler options/whatever you need to compile your package... and yes: do not use hardcoded paths in your Makefiles (or whatever you use to make your binaries)
Answer to this question really depends on what you want to achieve. If you want just to build you app by yourself then you can just write path to libraries in your makefile, or your code editor settings. You may not even have to do that as if libraries installed by your linux distribution package manager, headers usually go to /usr/include and libraries to /usr/lib or /urs/lib64 etc. That locations are standard and you do not need to specify them explicitly. Anyway you need to specify libraries you want to link to.
If you want to create application that can be build by others, or by you on many different configurations/environments using something like cmake would be very helpful.
I want to use a certain version of Qt4 in my project. I'm using debian and there is already an older version of Qt4 installed. When I'm using the find_package command in my CMakeLists file, of course, the system library is found, because the file /usr/share/cmake-2.8/Modules/FindQt4.cmake is used by cmake.
What I've done so far to link the newer Qt4, is to edit the paths with ccmake manually. The problem is I'm not allowed to install the newer Qt4 version in the directories of the system. Is there any easier solution to tell cmake don't use the system library just use another version. Of course I could create my own module and give the find_package command the path to my own module, but I think this is annoying and there have to be an more easier solution.
What I've also looked for, are there some environment variables which are used by the FindQt4.cmake module, but there aren't. - So, is there a general solution to avoid system libraries and to use libraries which installed in not system directories without doing some dirty tricks?
The only real way to use different versions of libraries on Linux is to use static linking. If you require the ability to use different versions of the same library simultaneously, you'll need to use an OS that supports that paradigm. Solaris (and its derivatives) is particularly good at that (compile with -L to point to the library to compile against and -R to indicate the path to that library at runtime). I believe BSD is the same.
Barring that, you'll want to create a chroot (a poor man's BSD jail) to deploy your application in. You'll install a copy of all the dependencies to the chroot, (use ldd to find them out) and the copy of Qt4 you wish to use.
Don't know about system libraries in general. For Qt, you set the search path to qmake and qt will do the rest. Qmake path is set through QT_QMAKE_EXECUTABLE, I use Qt commercial and this is how I set the path in Cmake.
set(QT_QMAKE_EXECUTABLE $ENV{HOME}/QtCommercialSDK/Desktop/483/gcc-64/bin/qmake)
I am trying to incorporate a libtool-based package into a project of my own, perhaps in a non-standard way. Here is my goal:
Build external project:
./configure --prefix=$HOME/blah --etcetera && make && make install
Build my own project which depends upon the external project's shared libraries and executables at runtime:
gcc -I$HOME/blah/include -L$HOME/blah/lib -o $HOME/blah/bin/program
Package everything into a single "localized" tarball... that is, while I have everything in $HOME/blah on the build host I want the ability to extract the tarball to any arbitrary directory (on some other host) without having to futz with my environment. The intent is to allow multiple versions of my project to coexist side-by-side without any nasty "cross-pollination".
I know that I can use -rpath '$ORIGIN/../lib' for my project to ensure that the right shared libraries always get loaded at runtime. However, it seems that libtool insists on assigning its own -rpath setting based on the exact path of $HOME/blah/lib, which breaks if I happen to untar everything into a different directory (say, for example, $HOME/blah.2011-06-02).
Is there a way around this limitation? I see a rather lengthy rpath discussion between debian and libtool folks on the topic, but it's somewhat old and inconclusive beyond "we disagree".
Among the options presented here on Rpathissue on the debian Wiki, using chrpath in your 'install' step or some post-processing script sounds like a viable option. (It's available on a bunch of distros via your favorite package manager.)
It doesn't require patching libtool which is a plus IMO.
Note that it has some limitations: can only save the new rpath if it's shorter (or same length) as the original one.
The other (pragmatic) option is to remove the rpath (chrpath can do that), and just have a wrapper script that sets LD_LIBRARY_PATH to whatever is necessary for your app. That has a chance of being slightly more portable too (if you handle the other shared library path environment vars some OSes have).