I am building a static library that uses AAssetManager (#include <android/asset_manager.h>) in C++ and then I will use the library from java.
The thing is I can't include libandroid because I can't use LOCAL_LDLIBS += -landroid when building static library.(local_ldlibs is always ignored for static libraries)
So how can build my static library without using local_ldlibs?
When you build a static library, you don't need to satisfy the external references, but if somebody uses your library, they must link libandroid.so. You can put this in documentation of your library.
If you provide an Android.mk with it, you can set LOCAL_EXPORT_LDLIBS = -landroid. BTW, you can also set LOCAL_EXPORT_INCLUDES to the directory with public headers for your library.
At any rate, NDK 10 is obsolete. I strongly recommend to move to the current release (unless you desperately need support for android-3).
Related
I am compiling a series of static libraries with precompiled header with MSVC2017 and CMake. So the generating is done manually:
Generating PCH:
/Yc /Fp"C:\FullPath\precomp.pch"
Using:
/Yu"C:\FullPath\src\pch.h" /FI"C:\FullPath\src\pch.h" /Fp"C:\FullPath\precomp.pch"
This all works fine. The libs compile and link fine (and a lot faster, so the precompiling works).
Now I want to use these libs in another project and get linker errors for the symbols used by the precompiled header. I can fix these errors by adding the precompiledHeader obj into the new project, but I dont like it. The projects which are depending on the libs should not be aware whether the libs were built with precompiled header or not. My Question: Is there a way to realize this with static libs that already links in all objects needed so that depending projects just link? I could imagine if it were shared libs it work out of the box. Is there a way to include the symbols of pch.cpp.obj into the using lib?
I want to convert my cpp code for static library into Android library.
For this, I'm attempting to use NDK.
But I read NDK documentation and it said that only source code is able to be input for building, "Android.mk".
My Questtion is "Is there any way to build static library for Android system with my cpp library?"
Top module of my cpp library is header file and it can be built on Windows system as ".lib".
Thank you!
Your cpp library should be built with NDK toolchain as "libyourname.a" to begin with. You don't need Android.mk for that, even though in many cases deriving a standards-compliant Android.mk is trivial, and makes the developer's life happier in the long run (See, e.g., github).
The next step should be to prepare a JNI wrapper dynamic library (shared object, .so), which can be loaded from your Java app. That "libyourname_jni.so" will probably have its own, separate Android.mk file. Well, Java is not a must: you can use NativeActivity, or maybe some alternative frameworks.
I suggest the following reading to understand the whole process: http://thesoftwarerogue.blogspot.co.il/2010/05/porting-of-libcurl-to-android-os-using.html
My solution contains several c# projects.
It's easy to add "refernce" from one project to another(References-Add Reference-Project). After that I can use classes from referenced project.
How can I do the same for native c++ projects? What kind of projects should I create? Console application/DLL/Static library?
There are two things in C / C++ :
Headers file, that will tell your program what they can use (e.g. class, function prototype declaration)
Implementation, either as a
source code that you recompile with your program
static lib (.lib on windows)
dynamic lib (.dll on windows)
You need both to compile your program with parts from another project.
If you only need a class from a big library and you have the source of this library it may be easier to reference the file corresponding to this class (and its dependencies of course). But if you need more, you should add the other project's directory to the include path of your current project in VCC, and link against the library (either static or dynamic, according to your needs).
I've got a 3d party static library built with some older version of MSVC, and I successfully link it to my application in MSVC10 (VisualStudio2010). Now I upgraded to MSVC11, and I'm unable to link it:
2>LINK : fatal error C1047: The object or library file 'MyLib.lib' was
created with an older compiler than other objects; rebuild old objects
and libraries
I guess this happens because the lib was compiled with /GL option, so the object files don't really contain COFF, but some intermediate format.
I don't have the library source-code to re-compile, and I don't want to make a dll out of it to link dynamically.
Is there a way - maybe some undocumented trick - to "re-compile" these obj's to COFF and eventually link them to MSVC11 application?
Even if this was possible, you don't want to do this: linking object files that are built against different versions of the CRT usually ends in tears. More specifically, if two such object files both use the C++ Standard Library, it is all but certain that you will violate the One Definition Rule (ODR).
If you cannot rebuild the module using Visual C++ 2012, then you should encapsulate it within a dynamic library, built with Visual C++ 2010, and avoid using any C++ Standard Library types in the interface of that DLL.
I don't know if it's possible to do this, but I would like the /NODEFAULTLIB to be applied to a static library project.
I have many application projects (A.exe, B.dll, C.dll) that use a common static library D.lib.
This library has a lot of code and also has other .lib dependencies as well. One of them is the openssl library, which seems to have been built for win32 against the Release version of the CRT (i don't have the original project/sources).
So far, to avoid the mixing of the Release/Debug versions of CRT, I have to put the /NODEFAULTLIB:msvcrt.lib linker directive in all leaf projects (A.exe, B.dll). This works but I think it's not the ideal way of dealing with that issue.
I tried to put this property in D.lib project, but it has no effect.
Is there a way to force msvc++ to ignore the msvcrt.lib dependency from the 3rd party library?
A .lib does not have any linker settings because you don't link it, you link to it. A .lib is just an archive of .obj files, sort of like an uncompressed .zip file - that's why you have to put the setting on all projects that link to it.
If you're using VS2005+ you could use property sheets so that you only have to put the setting in one place and then use that property sheet in all projects.
However, OpenSSL is just that - Open Source, so you should be able to get the source for the version you are using and build it again (and add it to your version control system of course). I thought OpenSSL could be built as a DLL or LIB, which would solve your problem as the DLL would not interfere with the linking of your code.
Failing that, you always have the option of slitting your functionality out into a separate DLL so that you only have issues with one project.
To prevent your distributed static link library from depending on a specific MSVC runtime library you need to set this compiler option (in Visual Studio 2010 it looks like):
Configuration Properties -> C/C++ -> Advanced -> Omit Default Library Name = Yes (/ZI)
Now your users can link to your release built static lib from their debug build and not try to link to the incorrect runtime library causing problems, as well as linkers warnings.
Note that may cause link errors if your library actually depends on a specific runtime library or its behavior, and compatible components are not provided in some other way.
My understanding is that if library LIB in linked statically into a DLL, the DLL contains already all relevant code from LIB. Therefore, this coupling cannot be removed. This is just based on my understanding of statical linking, not on experiments.