I have never had to use libraries other than ones that I have created, and even then I have simply copied the source files into the same directory as the remainder of the project. What are the steps to install and use libusb? I know that it is required to indicate to your respective IDE the pathway to the library, but to what exactly? To the folder containing the source? Is it necessary to precompile the libraries first?
I am not sure what to download from that link to get this going. There are options to sync via a repository to have the most up-to-date source, but is that necessary? I downloaded the tarball and have the source, but am not sure where to go from here.
Your compiler needs to know the path to the headers (.h), to find them when you #include and know which symbols (functions, structs ..) are available. Your linker needs to know the path to the corresponding compiled libraries (.o/.a/.so) containing the implementation. You don't need the source code (C/C++ implementation code, "private" headers) to use a library.
What you download depends on how you want to install it. If you are using a Linux distribution that already packages it, you can just install it using your package manager. You can get the newest version of libusb throught GitHub too, it is only "necessary" if you want something that is in the newest version. You can compile and install it in your /home or system wide. You can keep the sources in a separate directory next to your project's sources (git submodule can help to manage that), and compile them at the same time as your project. How you install them is your choice, then you just need to configure your IDE/build system accordingly.
Related
I had an old version of boost and it was working fine. But now there is no boost folder in the repo? What is the include path and where are the .hpp files please?
The Repo Link.
Looks like the version of boost you had previously was the release archive. This is the recommended and supported way to use Boost¹.
The release archives can be downloaded here: https://www.boost.org/users/download/ - they include what you expect.
What about Github?
The github repository is NOT a release archive. Instead it is a "super-project" that you can recursively clone to get all constituent libraries.
The headers are not part of the super - project (obviously, because they belong to the constituent libraries). If you want to do "modular boost" you should "build" the headers, which effectively links (or copies) the headers from the subprojects into the main include folder.
The build instructions for non-header only libraries are here:
https://www.boost.org/doc/libs/1_80_0/more/getting_started/index.html
¹ other projects might support other ways, like biicode, conan, vcpkg even Debian's apt install libboost-all-dev of course
I am trying to build a project via cmake in qtcreator, but am having trouble with the external package dependencies.
There have been several packages that it could not find, but I added symlinks to the actual file locations into the directory cmake was looking in, afetr which they worked fine.
However, this one library libopencv_viz.so.3.2.0 isn't cooperationg with me. I added the symlink and visually verified that the file/link is in the correct location, but cmake is still telling me that it cannot find the file, and I have no clue how to solve this. As I stated in a prior post, I am still just learning cmake right now, so I have absolutely no clue why it would not be able to find a package that is verifiably in the correct location.
CMake Error at /usr/share/OpenCV/OpenCVModules.cmake:192 (message):
The imported target "opencv_viz" references the file
"/usr/lib/x86_64-linux-gnu/libopencv_viz.so.3.2.0"
but this file does not exist. Possible reasons include:
The file was deleted, renamed, or moved to another location.
An install or uninstall procedure did not complete successfully.
The installation package was faulty and contained
"/usr/share/OpenCV/OpenCVModules.cmake"
but not all the files it references.
Creating symlinks by hand suggests you have an incomplete installation. Clean up your manual symlinks, and figure out what's wrong with your installation.
It is normal on Linux that the .so.x.y.z with the full numeric version is the runtime library. That is, the file that is required for applications to run. The version number ensures that the application loads the same library that it was built against.
The .so symlink to .so.x.y.z is for the build chain. When the compiler (linker, really) goes to link against libopencv_viz, it will search for libopencv_viz.so, resolve the symlink to versioned file, and link that.
Many distributions (including Ubuntu) separate the runtime libraries from the development components. My guess is that you've installed the package named libopencv-viz3.2, but not the one named libopencv-viz-dev.
I have an issue where I'm developing on one system where Boost is installed on:
/usr/include
/usr/lib
On a system I will deploy this on, the libboost libraries are at:
/nfs/mount/boost
/nfs/mount/lib
And I can't go about changing every system I deploy on to install libboost in the same place.
Is there a way to either:
include libboost as part of the binary executable such that loading from the system lib paths is not needed.
make the executable search for different directories when trying to load to libboost?
I'm using g++ 8
Sounds like you need a more sophisticated build environment.
I'm not sure what you mean here:
include libboost as part of the binary executable such that linking is not needed
Linking is not something you can skip. If you are trying to avoid distributing .dll/.so files with your executable, you need to avoid using the portions of the boost library that require compilation of the boost binaries (i.e. those not listed here https://www.boost.org/doc/libs/1_62_0/more/getting_started/windows.html#header-only-libraries).
Of course, that is not often the case. So...
make the executable search for different directories when trying to link to libboost?
This will never work reliably as you scale and is a nightmare in the CI world. This is where package managers such as conan (https://conan.io/) come to save the day. Delegating the package management to a third-party is the most reliable way of getting your code to build across multiple environments/platforms.
Also, building your executable and distributing it are separate operations. Any dynamically linked libraries will need to be discoverable on the system path at runtime.
I'm creating a very small project that depends on the following library: https://github.com/CopernicaMarketingSoftware/AMQP-CPP
I'm doing what i always do with third-party libraries: i add their git repo as a submodule, and build them along with my code:
option(COOL_LIBRARY_OPTION ON)
add_subdirectory(deps/cool-library)
include_directories(deps/cool-library/include)
target_link_libraries(${PROJECT_NAME} coollib)
This has worked perfectly for libraries like Bullet, GLFW and others. However, this AMQP library does quite an ugly hack. Their include directory is called include, but in their CMake install() command, they rename it to amqpcpp. And their main header, deps/cool-library/amqpcpp.h, is referencing all other headers using that "fake" directory.
What happens is: when CMake tries to compile my sources which depend on deps/cool-library/amqpcpp.h, it fails because it's not finding deps/cool-library/amqpcpp/*.h, only deps/cool-library/include.
Does anyone have any idea how i can fix this without having to bundle the library into my codebase?
This is not how CMake is supposed to work.
CMake usually builds an entire distributive package of a library once and then installs it to some prefix path. It is then accessible for every other build process on the system by saying "find_package()". This command finds the installed distibution, and all the libs, includes etc. automagically. Whatever weird stuff library implementers did, the resulting distros are more or less alike.
So, in this case you do a lot of unnecessary work by adding includes manually. As you see it can also be unreliable.
What you can do is:
to still have all the dependencies source distributions in submodules (usually people don't bother doing this though)
build and install each dependency package into another (.gitignored) folder within the project or outside by using their own CMakeLists.txt. Let's say with a custom build step in your CMakeLists.txt
use "find_package()" in your CMakeLists.txt when build your application
Two small addition to Drop's answer: If the library set up their install routines correctly, you can use find_package directly on the library's binary tree, skipping the install step. This is mostly useful when you make changes to both the library and the dependent project, as you don't have to run the INSTALL target everytime to make library changes available downstream.
Also, check out the ExternalProject module of CMake which is very convenient for having external dependencies being built automatically as part of your project. The general idea is that you still pull in the library's source as a submodule, but instead of using add_subdirectory to pull the source into your project, you use ExternalProject_Add to build it on its own and then just link against it from your project.
I have tried to install igraph by running the following commands (as described in the manual):
./configure
make
make check
make install
The installation instructions do not provide any further information where to go from here however. How do use the files in my ongoing projects (for instance in Eclipse)?
According to the manual, the installation process is adding files to the 'usr/local/bin', but this folder is empty after the installation (no hidden files).
What would be the easiest way to use the files in my C++ projects?
The installation process is adding include files in /usr/local/include (more precisely in /usr/local/include/igraph only) and library files in /usr/local/lib. Stick /usr/local/include to your include path in Eclipse, add /usr/local/lib to your library path in Eclipse, and add igraph to the list of linked libraries, and you are good to go. Make sure to use #include <igraph/whatever.h> in your C++ code to include igraph-specific stuff.
Also, this project tries to provide a more C++-like API for igraph. It is still experimental, the API changes all the time and many igraph functions are not wrapped in C++ equivalents yet, but it's a starting point that you can extend.