I'm trying to build a DLL library for Unity3D (in 32-bit) but first of all I want to make a .a static library to make a C++ Wrapper for C#.
Well, this is what I've done.
I've built OpenCV unchecking BUILD_SHARED_LIBS in order to get the STATIC LIBS, with architecture i386.
I've made my static library code and built it, Linking the static libraries that I needed (I really import them all because I'm having errors and I want to know if it's an error lib-based):
(included from /lib/ and /3rdparty/lib/)
I'm linking my library and header in a new project (Command Line Tool) in order to test my new static library, but my errors are:
(pastebin link)
Well, I have no idea what's wrong.
This is my settings on the static library:
This is my settings on my test Command Line Tool (for testing my library)
Does anyone have idea about this?
Thank you very much in advance.
Regards.
EDIT: tried to manipulate the static libraries for 64 bits as well but nothing happened.
The solution was removing several paths on the Library paths since it was messing up some libraries.
Related
I have some problems with linking my macOS app against C libraries.
I have several question related to this issue.
It is better to link app against dynamic or static libraries taking into account that this will be very custom libraries rather not shared with other apps?
I have linked my macOS Xcode app against ~14 static libraries .a and it works fine. I have reconfigured CMakeLists.txt making this libraries and now Xcode project doesn't work. The main change was changing the directory I have
"$(SRCROOT)/../../c/<project_name>/outputs/lib/apple/static"
But now I have both static (.a) and dynamic (.dylib) libraries in the same path
"$(SRCROOT)/../../c/server/outputs/lib/apple"
I don't know whether this should matter, but linking against static libraries causes that after running my Xcode project it complains that it cannot load lib.dylib So maybe it finds this dynamic library under Library Search Paths and tires to load them but don't find them linked?
So I tired to link Xcode macOS app against .dylib libraries and instead of static .a libraries added them in Link Binary with Libraries. The problem is that the error not finding library now also occurs.
Maybe I should change something here ? But what If I will distribute my app to some other computers that will not have libraries in this specific location. How can I include dynamic libraries in Xcode bundle in order to be always findable.
I know I added maybe to many question. But would like to know how to the best solve this issue? Better to link statically or dynamically and then how to correctly achieve this avoiding this error.
UPDATE
It seems that when linking against .dylib it only works when I add path to this library directory to Runpath Search Paths.
It also seems that when I link against static library .a it works when .dylib isn't in the same directory (I moved .a library into /static subdirectory) and then for this moved library error isn't showing any more. But isn't there way to link statically when there is .a and .dylib libraries inside the same directory?
I know this is an old question but it's one of the top results when searching google for "Xcode static linking."
I recently encountered this issue when integrating with Intel IPP, which puts static and dynamic libs in the same directory.
If I used the standard Xcode linking method of adding the library via the "Build Phases | Link Binary with Libraries," Xcode translated that UI into a command line that looked like this:
clang++ ... -L/my/path -lstatic1 -lstatic2 ...
But that causes the linker to prefer the DLL instead of the static library in the same directory.
I worked around this by removing the entries from the "Build Phases | Link Binary with Libraries" window, and adding full relative paths to the libraries in the "Build Settings | Other linker flags" entry:
../../path/to/lib/libstatic1.a ../../path/to/lib/libstatic2.a
This caused Xcode to translate the UI into a command line that looked like this:
clang++ ... ../../path/to/lib/libstatic1.a ../../path/to/lib/libstatic1.a ...
Which linked the libraries statically.
Finally, I have linked this Xcode macOS project with multiple dynamic C libraries (.dylib).
REMARK
In order to link with static libraries (.a) They cannot be placed side by side with dynamic libraries! path/project_name/outputs/lib/apple/*.dylib and then place static libs under path: path/project_name/outputs/lib/apple/static/.a As XCode tries to link dynamic libraries if they found them on Libraries Search Path in Build Settings.
DYNAMIC C LIBRARIES LINKIN IN XCODE
Add dynamic libraries to Build Phases tab and Link Binaries with Libraries section as on the image
Embed all this dynamic libraries in output macOS Application Wrapper
You get something like this:
Then in Build setting add Libraries Search Paths
And finally add Runtime Search Paths in Build Settings
I'd like to use a library (source codes from GH) in my JNI code. But the library depends on two other libraries (NTL and Boost) that are not available in Android NDK.
Now I am a bit confused and not sure if I understand correctly my following actions.
C++ code for Android is built into shared libraries (.so) for every platform (x86_64, armv7..). Does this mean that NTL, Boost and the lib I want to use must be compiled by me from source codes for these platforms too? If yes, how to do it correctly with cmake?
If I should build all the libs for specific platforms, how it is better to do, either as static libs (.a + headers) or as shared libs?
Do I really need to build NTL and Boost for all the platforms or I should do it just for the needed library?
Is Android.mk file required or can help with cmake? As I understand, it is used with "ndk-build" only.
Generally, if this sequence of actions is correct?
Build NTL for all platforms (.a + headers)
Build Boost for all platforms (.a + headers)
Build Library for all platforms (.so)
Add Library's .so-file as a dependency in CMakeLists for JNI project. (Do I still need dependent libs and headers or that dependencies will be incapsulated into lib?)
C++ code for Android is built into shared libraries (.so) for every platform (x86_64, armv7..). Does this mean that NTL, Boost and the lib I want to use must be compiled by me from source codes for these platforms too? If yes, how to do it correctly with cmake?
Yes, you'll need to build those libraries from source (or find a binary distribution for Android) if you want to use those libraries in your application. As for how to do that, you'll have to wait for someone else to answer or try Googling it. There are a handful of "how to build X for Android" tutorials out there, but I don't know if you'll find many for CMake since CMake is pretty new for Android.
If I should build all the libs for specific platforms, how it is better to do, either as static libs (.a + headers) or as shared libs?
That mostly depends on how many shared libraries you're building for your app. The ideal model for an app is to use a single shared library in your app and statically link in all of your dependencies (going to avoid linker bugs on old versions of Android, and will make your app as small as possible). If you have multiple shared libraries for your code, you'll need to use shared libraries for your dependencies to avoid ODR issues.
Do I really need to build NTL and Boost for all the platforms or I should do it just for the needed library?
You'll need to do it for any platform you need to use those libraries on.
Is Android.mk file required or can help with cmake? As I understand, it is used with "ndk-build" only.
CMake and ndk-build should both work, but you might have an easier time finding porting instructions for ndk-build due to CMake's relative youth in Android.
Linking these libraries was just like linking any other library.
But my issue comes when I run my project I am not getting linker errrors but my error is about "DLL"
I get
"The program can't start because DevIL.dll is missing from your computer. Try reinstalling the program to fix this problem"
I do not want the .dll. I linked the other libraries for a reason.
Or am I assuming wrong and DevIL will only work by me having to place this DLL in the system root?
Because my goal is to link DevIL without putting any DLLs in other places. I just figured I could use the the linker libraries like how you can with openGL.
If there's any good example let me know. I have also done some tutorials and a few examples but no luck. I keep getting this "DevIL.dll is missing" error window.
AFAIK ,the DevIL distributions come with import libs only.What you are talking about is called static library which is compiled into your executable and therefore doesn't require DLL.I tried to search for static libs of DevIL but didn't find.So you have to build DevIL from sources to compile static version by yourself.
I want to build a shared library that uses ZipArchive using GNU Autotools but I'm having this problem:
Warning: linker path does not have real file for library -lziparch.
I have the capability to make that library automatically link in when
you link to this library. But I can only do this if you have a
shared version of the library, which you do not appear to have
because I did check the linker path looking for a file starting
with libziparch and none of the candidates passed a file format test
using a file magic. Last file checked: /usr/local/ZipArchive/ZipArchive/libziparch.a
The inter-library dependencies that have been dropped here will be
automatically added whenever a program is linked with this library
or is declared to -dlopen it.
If I build a static library or if I use a shared library of ZipArchive it works but the problem is that the makefile that comes with ZipArchive source code only builds a static library.
How can I force Libtool to link with a static library?
Generally, static archives are created with non-pic object files and they cannot be put into shared libraries.
What this message is telling you though, is that when a program links to YOUR library using Libtool, that -lziparch will get added to the link. So you don't need to change anything unless you're building a module for an interpreted language. In that case, you will have to build ZipArchive as a shared library. In addition, this wouldn't work on a platform like MS Windows where shared libraries (DLLs) have to resolve all their symbols at link time.
All that said, if your ziparch static lib is PIC code, you can use the -whole-archive flag when linking it to your library. This would be the least portable solution though.
In MS Visual C++ 2010
I had a single C++ project in my solution which used boost and worked perfectly.
I then decided to convert this project into a static library and create a new project which depends on this static library.
Now, my converted static library builds without errors and warnings (compiler and linker)
but the new project compiles but does not link.
I am getting:
1>LINK : fatal error LNK1104: cannot open file 'libboost_thread-vc100-mt-1_45.lib'
As a test I added the full directory path to the linker options for this library... and then it complained about
1>LINK : fatal error LNK1104: cannot open file 'libboost_date_time-vc100-mt-1_45.lib'
I have now added complete paths to all the libraries and it now builds and run.
I am not happy with this solution because:
I don't want users of the library to
have to worry about linking in
boost.
It is messy
I know an answer would be to create a DLL but is there a way to do this statically and keep the linking at my static library level.
Edit:
If I tell the .exe linker to ignore the boost libs explicitly then it all is ok except the .exe should not have to worry about boost at all.
/NODEFAULTLIB:"libboost_thread-vc100-mt-1_45.lib" /NODEFAULTLIB:"libboost_date_time-vc100-mt-1_45.lib"
Apparently you don't need the .libs, as your exe also links without them. You seem to be using boost header-only methods and classes. So just tell boost to disable auto linking by defining the preprocessor symbol BOOST_ALL_NO_LIB in your project.
If you want to make your .lib unnecessary big by including all of boost, this question seems to hold an answer (which I never really tried myself): Linking static libraries to other static libraries
When building your library, you can include the boost libraries in yours. To do so, in VisualStudio's Librarian > General property page, list your boost libraries as Additional Dependencies.
However, there may be a problem if your clients use boost themselves, and statically link to it (especially a different version than the one you are using).
Did you build boost library? There are certain libraries in Boost that needs to be compiled. In case if you haven't done that, refer to "Getting started in Windows" on how to build the Boost library.
EDIT-1: Boost can be built both as a static and dynamically loadable (dll) libraries.
EDIT-2: If you have already built Boost, then the answer by #Daniel Gehriger tells you how to add it in VS.