Library management and search paths on macOS? - c++

I created a simple program that shows an image (bmp) file but now I would like to load a jpg file and I found the "SDL_image" library that seems to do what I need, the dmg file I have mounted, contains a file SDL2_image.framework and a readme.txt reading the readme.txt I see:
To Install: Copy the SDL2_image.framework to /Library/Frameworks
You may alternatively install it in <your home
directory>/Library/Frameworks if your access privileges are not high
enough. (Be aware that the Xcode templates we provide in the SDL
Developer Extras package may require some adjustment for your system
if you do this.)
My questions are:
is g++ searching in "/Library/Frameworks" and "MYHOME/Library/Framework" inside all the frameworks files in order to find the libraries I include in my cpp files?
ones the g++ has built the executable file, do I still need those frameworks/libraries in order to execute it?
if instead of the framework file I use the sources of SDL2_Image library what is going to change to the process?

Related

How to compile with c++ <execution> standard library

The issue
I am trying to use the execution policies in the standard algorithm library. However, when I try to compile I get the following error message
c:\mingw\lib\gcc\mingw32\9.2.0\include\c++\pstl\parallel_backend_tbb.h:19:10: fatal error: tbb/blocked_range.h: No such file or directory
After looking at various other related questions such as this or this, I understand that the execution library depends upon a software called tbb. Moreover in order to compile code which uses <execution> one has to manually link to tbb. My issue is precisely with how to download and link tbb to a script that uses <execution>.
I believe I have some serious gaps in my understanding in terms of how one downloads the correct files and then links to them. I will first make a list with my understanding of the linking process and then I will explain what I have tried to fix the issue. I have chosen this format so that it is faster for the one to answer my question to point at the issue at fault. I will attempt to keep this as concise as possible.
My understanding
Code is organized in header and cpp files, where the former usually only contain the interface to the software and the later the implementation
The cpp files can be pre-compiled and grouped into a single library file
For a user to then use the library, they have to #include the header/s in their script and also tell the compiler where the header files as well as the library file, are located
This can be done with the -I for the headers and -L, -l for the library file
-L provides the location of the library files, the -l specifies which libraries to use
What I tried
The script I try to compile is:
#include <execution>
int main() {
std::execution::par;
return 0;
}
with
g++ script.cpp -o out -I C:(path to the headers) -L C:(path to the library) -l (name of library) -std=c++17
I should also mention I am trying to do this on Windows 10
1st attempt
I had a particularly hard time understanding where to find the header and library files for tbb.
In the Intel getting started with TBB webpage, this github repository is listed as "TBB being available at". As I am used to header-only libraries I thought everything would be in the include directory but no .dll files where there. It is now my understanding that I have to compile the DLLs myself for my specific system which makes sense. I followed the following process using cmake:
# Do our experiments in /tmp
cd /tmp
# Clone oneTBB repository
git clone https://github.com/oneapi-src/oneTBB.git
cd oneTBB
# Create binary directory for out-of-source build
mkdir build && cd build
# Configure: customize CMAKE_INSTALL_PREFIX and disable TBB_TEST to avoid tests build
cmake -DCMAKE_INSTALL_PREFIX=/tmp/my_installed_onetbb -DTBB_TEST=OFF ..
# Build
cmake --build
# Install
cmake --install .
# Well done! Your installed oneTBB is in /tmp/my_installed_onetbb
However at the cmake --build step, cmake does not accept the command but requests more options. One of them is the dir option, which for which I made another directory and supplied it but then the error message Error: could not load cache printed out.
In any case, some files had been created so I searched for the .dll file but could not find it.
2nd attempt
I downloaded the Intel oneAPI Base Toolkit as is suggested here. After the installation at ../Program Files (x86)/Intel/oneAPI I found the specific tbb tool at C:\Program Files (x86)\Intel\oneAPI\tbb and I used this address for the -I and -L flags but initial error message persists.
I also copied the directory C:\Program Files (x86)\Intel\oneAPI\tbb\2021.6.0 to the local directory of the script so I could link with -flag tbb\2021.6.0 but no luck
Many thanks
Yes you were correct.
By using the package mingw-w64-tbb. You can use -ltbb12 instead of -ltbb. As the library files are related to ltbb12.
For using -ltbb option, you should set the Intel oneAPI environment. It can be used by downloading Intel oneAPI Base Toolkit.You can set the environment by sourcing setvars.sh file using the below command.
source /opt/intel/oneapi/setvars.sh

Is it necessary to install the NDK to use a .so library?

I have a Android project that is a library (with the Is library checkbox marked) and other Android project that need these libraries. In the library there are three .jar packets and a folder called armeabi that contains 7 files with .so extension.
I have added the .jar libraries in the Java build path, libraries tab.
But I can't manage to add the libraries to the project that need these libraries. I would like to know if there is any way I can add these libraries without installing the NDK.
In case I need to install the NDK, how should I proceed to add the .so libraries?
Thank you very much
You don't need the NDK to use an *.so file, only to build one yourself.
If you need the *.so files for an app, just place them into the /libs/armeabi directory of your project. They will end up in the APK created by the Android build system.
One thing to watch out for are bugs / undocumented behaviour with the files' names. I once had an inexplicable problem with an *.so file whose name didn't start with "lib"; it was in the APK but would be ignored by the installer on the device. Only when I renamed it would it correctly be installed.
If you need the *.so files for a library, you basically don't do anything. The Android library system is not very sophisticated and even worse than what Java already offers in this area (in my opinion); there is no way to create an Android library which has everything included in one single file. So if the Java code in your *.jar archive needs the native functions in the *.so files, then you'll have to ship both the *.jar and the *.so files to your clients, as separate files. (Of course, the clients will then do the same thing which I explained above: place the *.so files in their app project's /libs/armeabi directory.)
You need the NDK only to build .so files, it does nothing for packaging.
The .so files are usually stripped from .jars on Android, if you want to get these into your app your need to extract the files yourself and put them inside /libs/armeabi/, /libs/x86/, etc for eclipse, /jniLibs/armeabi/, /jniLibs/x86/, etc for Android Studio.
If you want to package your library and get its .so files integrated automatically when used, you can package it as a .aar instead of a .jar and use gradle: http://tools.android.com/tech-docs/new-build-system/aar-format.
Inside the .aar, your .so files for each architectures should go inside jni/armeabi/, jni/x86/, etc.
Libraries that you build (with the NDK) generally come out in the libs/armeabi directory of your project (I don't know for sure if you can change this).
But seeing that you already have your .so file, I think it's safe if you manually put it in the libs/armeabi folder. Then it is automatically packed with your apk.

How to package C++ with dlls and libraries

I'm wondering how to "package" a C++ project for release. It uses various libraries, and I don't want a user to have to go through the same setup I did, with putting the right files in the right place and such. I had difficulty researching this, because I'm not sure the technical term for this issue. If I'm using command line compiling on Linux, is there an easy way to do this?
Your approach to this will differ on Windows and Linux because each OS handles this a different way. I'm more familiar with Linux so I'll restrict my answer to just the Linux side of things.
When you link your executable with a library using -l flag the linker defaults to looking in the normal system library directories so there are four approaches here.
Require the user to properly install the libraries themselves. However, it sounds like you don't want to do that.
Have the user add the library location to LD_LIBRARY_PATH variable.
Your third option is force the linker to look in a certain path for the libraries using the -rpath flag. For example, to have the application look in its working directory for a shared library you can compile with: g++ -rpath ./ -l SomeLib -o MyApp myapp.cpp
One other option is to static link your code with their library that way you only have to distribute one executable. If a static library exists you can use g++ -static -l SomeLib -o MyApp myapp.cpp to tell gcc to link statically.
On windows I would recommand wix http://wix.sourceforge.net/ to create the .msi installer
I would like to point out, the lookup path for .dlls I recommand putting all .dll in the same folder as your .exe since this has the highest priority
However, the vc crt (the c/c++ runtime library) should be installed using the redistributional package from microsoft -> updates automatically http://www.microsoft.com/de-de/download/details.aspx?id=5555
Wix can include the redistributional package into the same .msi therefore you have only to deploy a single installer file.
You mean an installer?
On Windows the program that you run to install a new app which outs everything in the correct directory, creates the start menu and lets you un-install it?
There is an installer builder in Visual Studio (might not be in the free express version) which makes .msi installer files. It's fairly easy to use for simple tasks but becomes complicated to do anything more.
Alternatively, to create traditional setup.exe type installs I use the excellent free Innosetup
On linux you would generally create a package using whatever format your distribution uses (.deb / .rpm ). There are lots of instructions on the specifics of each one and the tools to do so will probably already be installed in your Linux system

exploiting poppler in Qt creator - help

I am trying to compile a Qt project that uses poppler library for pdf (linux).
I put #include in the mainwindow.cpp
I put poppler folder in my project folder besides mainwindow.cpp
poppler-qt4.h is in poppler-0.16.7/qt4/src
I do not need to recompile poppler, I just need to link the library through its headers but I do not know how to do. If compilation is necessary I can do it, but I tried ./configure and it said "./configure not found".
I searched for other similar threads but they were not enough useful to me.
I know LIBS is involved but makefile is overwritten by Qt-creator?
I'd prefer to learn how to "officially" inform Qt-creator that I want to add the library.
Please can help?
You have a good example, completed with source code, here: Poppler: Displaying PDF files with Qt
Along with including the header files where apropriate, you need to link to the poppler library.
To do so, you need to edit your .pro file and include something like:
INCLUDEPATH += /usr/include/poppler/qt4
LIBS += -L/usr/lib -lpoppler-qt4
These are the "default" paths, you may need to change them accordingly to your particular install location.
EDIT:
From your comments you seem to be trying to build poppler lib from source. The problem is that you're executing ./configure ( make and make install ) in the wrong directory. You "need" to position yourself in the directory where the file configure is located(*). Then execute the traditional commands:
./configure
make
make install
You run configure (you usually have to type ./configure as most
people don't have the current directory in their search path). This
builds a new Makefile.
Type make This builds the program. That is, make would be
executed, it would look for the first target in Makefile and do what
the instructions said. The expected end result would be to build an
executable program.
Now, as root, type make install. This again invokes make, make
finds the target install in Makefile and files the directions to
install the program.
I extracted this quote from http://tldp.org/LDP/LG/current/smith.html. But there are lots of places where you can find more information about these commands. Just google it! :D
(*) You don't really need to be in the same directory as the configure file. But it's easier than writing the full path.

Packaging Linux software while keeping a sane file structure

So I have created a piece of software which I wanna package and post to Arch Linux User Repositories, AUR, -should note, that I have never packaged anything for any distro before - and I have also got it packaged and installed on my own machine via Arch's package manager Pacman successfully, but now I am wondering how on earth am I gonna structure the folders and files?
Normally when I wrote software, I use this structure:
build/ | src/ | makefile
As a minimum, and in the case of this piece of software, the makefile does nothing more than compile a .cpp file from src/ to build/.
To make the Arch package, I also had to create a .rc file, to use the program properly as a daemon and the PKGBUILD file, which is the file that tells the makepkg program how to build the installer-package - these two files, though, are specific to Arch.
If I wanna package the program for say debian, I would need another set of files to do this too, but these files only work for debian. Now, I can't just put the .rc file and the PKGBUILD file in to the programs root folder, since that would "be a mess" especially if I also had files to build a package for debian, but where do I put the distro-specific files? I need to have it in the programs root folder -at-least- to be able to keep track of it, and my initial thought was to go with a structure like distro/arch/ for Arch Linux specific files, and then the PKGBUILD file would just run the makefile in the programs root folder and copy the compiled file from build/ to distro/arch/ before it did anything else, but I discovered that I couldnt get PKGBUILD to work that way, and people on #archlinux on Freenode also said it was not a smart idea.
So where do I put the distro specific files? If I knew I only had to provide this program for Arch, it would be easy to just structure it only for Makepkg, but I dont like to imprison the softwarelike that, and I could also imagine providing packages for other mayor distros like debian, so how do I achieve this while keeping a sane file structure?
Regards,
Chris Buchholz
Very often you find in tarballs a directory called 'debian' which has the debian specific files in it. I would go the same route and create a directory 'archlinux' and put the files there.
Then I would go on and put a file README in the archlinux directory that explains how to use the PKGBUILD properly.
One solution could be to write a rule into your Makefile 'package-arch' that copies the PKGBUILD into the root directory, runs makepkg, then deletes the redundant PKGBUILD.
It's hackish, so I would also write a bug report for the Arch people to fix this limitation. However, did you try makepkg -p archlinux/PKGBUILD?