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.
Related
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 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.
I'm developing an application using Qt and OpenGL, and found it necessary to download the GLM library. It's a header-only library, so I don't need to link to anything. I want this application to build on any system that has the correct libraries installed. My problem is that I don't know where to put GLM so that the system can find it without adding a specific path to the project's .pro file. The .pro file is part of my git repository, which is how the source is distributed to other systems like Linux, etc. So I don't want this file to specify the exact location of GLM because other systems could have it in other places.
I'm currently developing on Windows, compiling in Qt Creator using Visual C++ 2010. I read from MSDN that #include <file> searches using the INCLUDE environment variable, so I tried to add the path to glm.hpp to INCLUDE, but QtCreator's build environment for this project seems to overwrite INCLUDE. So I appended the path to GLM to the new INCLUDE from within QtCreator's Projects tab, but my code still can't find glm.hpp.
In general, how can I add an external library to my system such that my compiler will be able to find it without specifying the exact location in a project file that's distributed to other systems?
What you need is a build system with the power to search the system for the libraries you request, and be able to do so on any platform. One such build system is cmake, and it is the most widely used build system. In essence, cmake allows you to write a build script in which you can specify all the things you normally specify when creating a project in Qt Creator or Visual Studio, like the list of source files, grouped by targets to compile (libraries, executables, etc.), the relative paths to the headers, and libraries to include for linking and for include-paths, amongst many more things. For libraries that are installed on the system, there is a function, called find_package() (part of cmake script commands), that will find out if the library is installed and where to find its lib files and headers (storing those paths as cache strings that you can specify on the targets and such). It usually works great, as long as the libraries are not installed in weird places. The way it works is that when you run cmake, it will generate a build script/configuration for almost any platform you specify, and then you use that to compile your code. It can generate makefiles (Unix-like or windows), CodeBlocks project files, Visual Studio project files, etc.. And many IDEs also have native support for cmake projects.
I wish I could recommend an alternative, just to sound less biased for cmake, but I haven't heard of any that truly compare to it, especially for the purpose of locating external dependencies and working with different platforms. I would guess Boost.Build is decent too.
How can I use libcurl with my project without actually installing it or curl on the system?
I want to make my source-code portable, so that any developer can copy the folder with all sources and other files, run make and compile the program without the need for system level installations.
I am looking for (probably separate) solutions for Linux and for Windows (dll?). If it is possible, provide some standard/official solution and not hack (I'd like to be educated about linking third party libraries)
I've used it on Windows using Visual Studio, all you need to do under Windows:
Download the source
Using CMake generate the project files (when using Visual Studio).
Build the libraries, 3 files will be built: libcurl.lib, libcurl_imp.lib and libcurl.dll
Include curl.h in your project and add the paths to your .lib files
Build your program, put libcurl.dll in the executable folder and it will work.
On Linux it should be a similar process, build the libraries and include them with your source.
You probably want to build a static library out of libcurl and link agains it. Should be pretty straightforward and the process is almost identical on every OS.
I'm trying to build a .dylib in Xcode. Currently the .dylib builds, but when I drag the .dylib into another project and try to #import one of the headers (Seeker.h) in the .dylib, I get this error:
*: No such file or directory
Seeker.h: No such file or directory
The project is available as an Xcode project here.
I can confirm the header is indeed in a path alongside the .dylib once built, but as for what to do with it I have no idea. My only experience with .dylib files is frameworks built into Mac OS X, like libsqlite3.dylib, which works perfectly. All the tutorials I can find on .dylib files does not cover how to use them with Xcode in a sensible manner; all of them rely either on complex scripts or machine-dependent configuration which will not work for us.
So basically I need a start-to-finish step-by-step process that successfully builds the .dylib and successfully includes it in another Xcode project in a way that's not dependent on changing build settings for different users. In other words, a way that just works and that will work when we distribute both projects to members of our team.
Dylibs don't carry headers: they're brainless executable files. Built-in libraries have their headers in known locations, like /usr/include, which makes them globally available. What you're looking for is probably a framework.
Frameworks are packages that contain a dynamic library and header files, so once you link with the framework you can import the headers it has. It can also carry other resources such as images and sounds.
I suggest you read the Framework Programming Guide for more informations.
You are not able to create static library .dylib from Xcode because they are using OS, but you are able to create a dynamic framework with .dylib inside
[iOS static vs dynamic library]
[Create dynamic framework]