I am using Android Studio 3.0 for my NDK based app.
For the C++ code, I use CMake as the external builder.
This works well, I can create debug and release binaries.
However, I would like to turn on compiler optimizations (say -O3) for a part of the C++ code (the physics engine), not just for the release build, but also for the debug build.
So create the bulk of the debug build as is, without optimizing, yet, I want one of the static library targets to be built with the compiler optimization enabled.
How can I go about this?
I have a CMakeLists for a static library target that gets included using add_subdirectory() directive in the top level CMakeLists file.
Note that I point to the top level CMakeLists in my app's build.gradle file like this:
externalNativeBuild {
cmake {
path '../../Android/jni/CMakeLists.txt'
}
}
It turns out that you can use the target_compile_options() macro in your CMakeLists.txt with a config specification like this:
target_compile_options(opende PRIVATE
"$<$<CONFIG:RELEASE>:-O3>"
"$<$<CONFIG:DEBUG>:-O3>"
)
This macro adds to the existing compile options.
Related
I have the following projects in a Visual Studio 2012 solution:
Native (no /clr) static lib project, compiled with /ZI for Edit And Continue.
C++/CLI DLL project, which references the above static lib.
The C++/CLI project builds with the following warning:
warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/OPT:LBR' specification
If /OPT:NOLBR is added to the linker options of the C++/CLI project, the warning becomes:
warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/INCREMENTAL:NO' specification
Any attempt to change the incremental linkage setting of the C++/CLI project doesn't change the warning (C++/CLI projects never link incrementally anyway).
I understand that I won't be able to use Edit And Continue in the C++/CLI project, because this is not supported. Indeed, changing /ZI to /Zi (disabling Edit And Continue) in the static lib project eliminates the warning, but I can't do that - other non-CLR consumers of that lib need to use Edit And Continue.
How can I get rid of this warning without disabling Edit And Continue in the static lib (and hopefully without maintaining separate build configuration for native and CLR users of the static lib)? I mean, is there any way to ask the linker to ignore the /EDITANDCONTINUE directive that is embedded in the referenced static lib (much in the same way that /NODEFAULTLIB can ignore /DEFAULTLIB directives)?
I have created a minimal VS solution that reproduces the described issue.
due to '/OPT:LBR' specification
This is a nonsense error message, that linker option is only effective for ARM binaries. This is simply a bug, using /OPT:NOLBR takes the sting out of it and you get the real warning.
Which is accurate enough, although it doesn't win any prizes either, you asked for Edit+Continue support in your static lib project but that is not available for a mixed-mode .NET assembly. The undocumented /IGNORE linker option is available to suppress warning messages but this one is ranked as an "unignorable warning" by Chapell.
You'll have to live with this warning as long as you don't want to change your static lib project. It is completely benign. You won't get it when you recompile it with /Zi.
There is no other way than to
disable "Edit And Continue" in the library
create a separate build configuration for "Edit And Continue (/ZI)" and "Program Database (/Zi)"
Of course: I am not aware that there is a predefined macro to determine between /ZI and /Zi... so you need to define your own preprocessor directive to distinguish between these configurations...
I had the same problem and found the only solution is to delete the .vcxproj and .sln files of the project and create the project again.
But then in an old copy of the same project I found a better solution: I changed in the projectname.vcxproj file the line
Profile true
to
Profile false
and LNK4075 warnings disappeared.
It had been the Visual Studio Profiler who had caused the troubles.
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 visual studio project uses the dll ftcspi.dll to talk over usb/spi to the device.
I want to not to have to use the dll but to use the .lib file instead.
So in the settings I have FTCSPI.lib added to ProjectSettings->Link->Input.
I have changed the ProjectSettings->Link->General->additionLibraryDirectories t have the location of ftcspi.lib in it.
The exe still doesn't work without having the FTCSPI.dll present.
If the project (FTCSPI) is set to compile as a dynamic library, then the .lib you see there is just a file to help the compiler link to that dynamic library (dll).
You would need to compile FTCSPI as a static library to achieve what I think you want to achieve.
Configuration Properties -> General -> Configuration type.
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.
I am trying to maintain a program written 5 years ago in VC++ 6.0. It uses our 'common' libraries. The trouble I have is that it either links against the debug version of these libraries or the Release version, depending on whether I have the [Directories] for [library files] set to "common/debug" or "common/release" in [Tools]->[Options].
How do I get it to link to [common\debug\common.lib] when building the debug version and [common\release\common.lib] when building the release version? If I have both paths in the library directories, it seems to link to the first one it finds.
Instead of specifying the paths in the include folders and all the best way i use to include the libraries depending on the configuration is by using #pragma
try this once, it is very useful
#ifdef _DEBUG
#pragma comment(lib, "..\\DllTest\\Debug\\DllTest.lib")
#else
#pragma comment(lib, "..\\DllTest\\Release\\DllTest.lib")
#endif
In [Project Properties]->[Linker]->[Input]->[Additional Dependencies] you can use the $(ConfigurationName) placeholder, like this:
c:\common\$(ConfigurationName)\common.lib
In the Debug configuration this will change to:
c:\common\Debug\common.lib
and in Release it will change to:
c:\common\Release\common.lib
If I have both paths in the library directories, it seems to link to the first one it finds.
Just add the debug folder for the debug settings and the release folder for release settings.
Almost all compiler, linking etc. settings are per configuration (the project properties will show settings as blank in "all configurations" (if I recall the right text) if debug and release are different.
You could specify the full path of the library to link to in the Additional Dependancies field, this can have different values for debug and release builds.
The solution I have found is a little like Richard's & "1800 Information"'s...
I removed the Common library path from Tools->Options. The paths in here are global to all configurations of all projects running in MSVS VC++ 6.0.
I then added a full path to the appropriate library in Project->Settings for each configuration. Hense the debug configuration has D:\VSS\Common\Debug\Common.lib and the release configuration has D:\VSS\Common\Release\Common.lib. This seems to work and for the first time I have no build warnings!
Thanks to all the suggestions for pointing me in what seems to be the right direction.
--- Alistair.