I am programming applictions written in C/C++, in my project I am using SMFL library for my GUI.The way I use SMFL is that I built it from the source,and link the compiled library.So the procedure can be summarized below:
install the libraries dependent by SMFL, that is "pthread opengl xlib udev xrandr xcursor freetype openal flac vorbis";
build the SMFL source and get the final library files;
build my project using the SMFL library file;
So the application I built could be distributed to others.
Then a question arises, do other users who get my built application have to install the libraries used by SFML(i.e. pthread opengl xlib udev xrandr xcursor freetype openal flac vorbis)?
Yes, all dependent libraries must be installed. Referencing udev and xlib indicates that you're most likely referring to Linux.
If you build and deploy your application using a Linux distribution's native package manager, like rpm for Fedora-based distributions, and apt for Debian-based distributions, then installing your rpm or deb package will result in all dependent packages getting automatically installed as well, making this process a moot point.
A quick check shows that SFML is a popular library that's already available in most mainstream Linux distributions. There is no apparent reason to build it yourself. Just use the one that already comes with your Linux distribution, and save yourself all those headaches.
There are some edge cases that call for building a custom or a different version of a library that's already included in the distribution. In that case that library can also get build with rpmbuild or debuild. The only additional twist here is that additional, advanced techniques must be used to make it possible to seamlessly have the custom-built library installed alongside the one that comes with the Linux distribution.
But, taking advantage of your Linux distribution's native package management tools is the easiest way to handle these kinds of common dependencies.
Related
I have a C++ project that I share with some colleagues. The development operating systems are different among us, usually divided between MacOS and different Linux distros.
We already use different libraries, that we use to paste in the lib folder and they are ready to use for us.
We need to use Boost and, for some reason, it looks like the way it works is different by other libraries and it needs to be installed on the system, like this question asks.
It looks like that installing Boost on the system is a de-facto standard, and many people give it for granted, even if I didn't see any reference to it and I don't see any good reason to do it, since it makes the source code less portable because of external dependencies and different IDE configurations. While having an IDE-independent configuration would actually make more sense.
So what are the advantages of one way over the other?
What's the difference between installing boost on the system and paste it locally in the project?
If you install a library on the system, then it will be found from the default include / library archive directories, and the compiler / build system will find the library without special configuration. If you install a library elsewhere, then you need to configure the compiler / build system to find the headers and the archives from where you've copied them.
The way to install library can vary across different systems.
it looks like the way [Boost] works is different by other libraries and it needs to be installed on the system
No, Boost is not special in this regard. It can be installed in a system directory, and elsewhere.
Regardless of where you install the library, I recommend using a package manager.
If you install using the system package manager, then you will be limited to the version provided by the system. This is an advantage when targeting that particular system, but a potential problem when developers use a variety of systems.
A system package is often better because it is adapted to the specific environment of the given system by the packager. Moreover, using a system package means the application is more likely to work correctly on users’ systems because then you can package it, getting the runtime library as a dependency.
I'm trying to create a cross-platform application that is using client applications written in C for MariaDB. But MariaDB offers a different library for each operating system and architecture for each of these. I need to know if there is a way to set up a C++ project for when you compile on Windows then take Windows libraries and when I compile on Linux then take the Linux ones.
On linux you'll want to use the distribution's repository's mariadb, on Windows, you'll need to compile it yourself or ship the official release.
It's best to use something lik CMake which allows you to either detect the presence of a library or let the builder point it to where it can be found at build time, and don't hardcode any paths or crazy platform-dependent search paths into your build system's project file.
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'm starting to look into deploying a Qt application I've been developing but I've never had to deploy any C++ application before this.
I want to be able to ship my product as a pre-compiled executable that dynamically links against shared library files(Qt) for Linux/Windows so that there is an executable that looks in its own sub directories for libraries instead of libraries that may be installed as a result of other Qt products.
Is this something that is possible? Or must the Qt library files be installed separately for an application to link against them? I want to avoid requiring the end user to install ANYTHING on their systems while also avoiding static linking.
This is a normal behavior for Qt. How to do it greatly depends on your build system.
If you use CMake, you can generate installers with CPack. Here is a link to adding the required shared libraries to an installer. CPack makes many different types of installers for Linux, Windows, and Mac OS X.
You can also generate your own installers using NSIS. This is a lot more involved but doable.
Qt has documentation on how to deploy applications that use their libraries.
At my company, we do both CPack and NSIS. The CPack way is a lot easier and there is more examples online.