I'm building a C++11 program that works on osX, but the build for android fails with "error: 'round' is not a member of 'std'".
This is a known problem, associated with the gnustl standard library (https://code.google.com/p/android/issues/detail?id=54418), and the current best workaround seems to be to link against LLVM libc++.
How to do so is documented here for Android Studio or cmake, but I cannot find any documentation for how to do the same with bazel, if it is possible.
A partial answer:
if just building an android static library, the command line call has to specify crosstool_top. This can be set to a specific toolchain using something like --crosstool_top=#androidndk//:toolchain-libcpp.
Options can be found in external/androidndk/BUILD in the directory generated by bazel.
However, if building the library as part of an android application, the crosstool would be inferred. I don't know whether the same approach works, or if not what the answer would be.
Related
I have code that I want to conditionally compile depending on the target SDK version, so that I can use newer features if possible. This can be done by checking the __MAC_OS_X_VERSION_MIN_REQUIRED macro, which tells us the target SDK version, in the source code.
Typically, performing conditional compilation on that macro suffices, and everything is nice and good. However, when targeting a newer SDK version, I would like to use features from a new library (specifically the UniformTypeIdentifiers library) that is not available on an older SDK version. This means that the target_link_libraries() in CMake has to account for this, i.e. link the new library if targeting a newer SDK version, and skip the new library otherwise.
I can't seem to find any way to figure out the target SDK version in CMake. What is the proper way to do this?
Things I have tried:
Checking CMAKE_OSX_DEPLOYMENT_TARGET. This flag is what CMake uses to pass the -mmacosx-version-min flag to clang, that makes it use a particular deployment target. However, it turns out that this may not necessarily be defined. When not defined, clang doesn't get the flag, but since clang is given something like -isysroot /Applications/Xcode-13.3.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk, the framework sets __MAC_OS_X_VERSION_MIN_REQUIRED to something default (12.3), and so the source code is able to still perform conditional compilation.
Checking if the library exists by using find_library() (e.g. find_library(UNIFORMTYPEIDENTIFIERS_LIBRARY UniformTypeIdentifiers)). This does not work when users want to target a lower version (e.g. by setting CMAKE_OSX_DEPLOYMENT_TARGET), since the new library will still exist.
Essentially, I would like a way for CMake to figure out the deployment target that ultimately gets chosen (i.e. something equivalent to __MAC_OS_X_VERSION_MIN_REQUIRED), so that it can decide whether or not to link with the new library.
How should I do this?
Context:
I'm trying to resolve an issue in my library here.
I also have a testing branch set up to check CMAKE_OSX_DEPLOYMENT_TARGET and the compiler command in the CI builds: GitHub CI builds MacOS 10.15 (without the new library, with CMAKE_OSX_DEPLOYMENT_TARGET) and 11 (with the new library, with CMAKE_OSX_DEPLOYMENT_TARGET), and Circle CI builds MacOS 12 (with the new library, but without CMAKE_OSX_DEPLOYMENT_TARGET).
I couldn't find a way to determine this via some CMake variable, so I rolled by own compilation test for it:
include(CheckCXXSourceCompiles)
check_cxx_source_compiles(
"
#include <Availability.h>
#if !defined(__MAC_OS_X_VERSION_MIN_REQUIRED) || !defined(__MAC_11_0) || __MAC_OS_X_VERSION_MIN_REQUIRED < __MAC_11_0
static_assert(false);
#endif
int main() { return 0; }
"
NFD_USE_ALLOWEDCONTENTTYPES
)
This ensures full consistency with the check in the source code, at the cost of a slightly longer time to configure the build.
I'm trying to use LLVM to implement a compiler for a toy language. Something like the Kaleidoscope Tutorial. I'm using Visual Studio on 64 bit Windows.
I've managed to build LLVM and clang using VS, but now I want to use the LLVM libraries in my own project. It seems like a silly question but how to I do this? What compiler options do I need? What libraries should I link with etc. etc.
As far as I can see this isn't covered anywhere in the LLVM documentation although I could have easily missed it.
I discovered llvm-config which is designed to solve the problems I'm having. It often seems to give incorrect information (for instance llvm-config --includedir is wrong) but it at least gives me a list of libraries to link with.
I suppose I could also use CMake to generate project files, but CMake seems to be difficult to learn from free resources.
I want to force Xcode to use a custom compiler ('clang-llvm' build from the src) so I can use the clang plugin. My Xcode version is 7.3.1.
People say it is possible with custom toolchains. I didn't make a research on them because easier solution worked well for me:
It is also possible to run frontend plugins directly by setting appropriate "build settings" of Xcode. (Several ways to do this, you can set them on the command line for instance: xcodebuild build FOO=bla.) Here are a few build settings that I found useful to inject C flags:
OTHER_CFLAGS, OTHER_CPLUSPLUSFLAGS or to replace the compiler(s) and linker(s):
CC, CPLUSPLUS, LD, LDPLUSPLUS, LIBTOOL
The same approach works to control the "analyze" action: CLANG_ANALYZER_EXEC, CLANG_ANALYZER_OTHER_FLAGS
Disclaimer: some of those build settings are undocumented (afaik). Use at your own risk.
(Taken from [cfe-dev] Compile/refactor iOS Xcode projects)
For me it was enough to define the following User-Defined Settings in Build Settings of Xcode projects:
CC=my-c-compiler
CXX=my-cxx-compiler
LIBTOOL=my-linker-for-static-libraries
If you use CMake, the way to inject your compiler automatically is to use
set_target_properties(your-target PROPERTIES XCODE_ATTRIBUTE_CC "${YOUR_CC}")
set_target_properties(your-target PROPERTIES XCODE_ATTRIBUTE_CXX "${YOUR_CXX}")
Couple of years ago I've written an article that addresses exactly the problem you describe: Creating and using Clang plugin with Xcode
To enable custom clang you need to actually patch internals of Xcode.app itself, it is technically doable but:
it will break when you update Xcode
it will work correctly on your machine
the version of a plugin and your compiler should match, i.e.
they should be compiled using the same tree
So in general it doesn't really scale, so be careful :)
There's a somewhat obscure feature of Xcode where it supports "alternative toolchains". For example, Swift.org provides installable toolchains for Swift built from current sources.
Unfortunately, while Apple's documentation describes how to install and use such alternative toolchains, it doesn't describe how to create them. There are scripts in the Swift source base which build a toolchain and you can look at them to figure out how it's done. They are in https://github.com/apple/swift/tree/master/utils. Start at build-toolchain, which calls build-script and go from there.
Method 1: Change the User Defined settings
Under the project or target Build Settings add the User Defined settings for
CC=/path/to/cc
CXX=/path/to/c++
This is useful if you have a single compiler or linker you want to call, or if you want to call out to a trampoline that decides what to call on the fly.
Method 2: Create a complete custom toolchain via plugin
Using Clang LLVM 1.0.xcplugin as a template (found in the Xcode.app plugins folder), you can modify the plist to point at your own alternative compiler and linker.
This OLLVM on iOS tutorial walks through it.
From project setting go to build setting with target selected. then select All beside the Basic from the top bar. then under build option you can see the compiler option.
Refer below screenshot,
Update :
I think you should refer Using C and C++ in an iOS App with Objective-C++ and this tutorial.
I'm having trouble linking an Xcode project using the AAF SDK, with Xcode 5.1.1 on MacOS 10.9.5. When I link the main dynamic library, these symbols come up missing:
_StgCreateDocfile
_StgCreateDocfileOnILockBytes
_StgOpenStorage
_StgOpenStorageOnILockBytes
AssertProc
I can't find a definition for them anywhere in the entire source tree for the SDK. The first four appear to be part of Structured Storage on Windows. A Structured Storage library is provided in the SDK and I'm already linking that.
Can anyone tell me of a Mac system library that defines these? Or is there a linker argument that pulls in a library for them? Thanks for any help.
A late answer (!), but in case anyone comes across this... The solution is either:
To use the makefiles with the AAF SDK to generate the AAF dylib,
which works fine. or...
If you use Xcode to build the AAF SDK, ensure the correct
#defines are kept, namely:
_DEBUG OM_DEBUG OM_STACK_TRACE_ON_ASSERT OM_USE_SCHEMASOFT_SS OM_STRUCTURED_STORAGE
Note that DEBUG=1 is absent (it is added by default by Xcode) - if defined, this brings in AssertProc. Define NDEBUG on release builds and omit the debug defines.
The Stg... functions are part of the MS implementation of Structured storage as you stated, but should not be referenced on a Mac, the Schemasoft implementation being used.
I am atempting to build a Multiplatform desktop application using WxWidegts. As the IDE I am using Codlite. Version info is
Codlite: Revision 5770
WxWidgets: 2.9.4
OS: Windows 7
Compiler: g++
The problem is, after compiling, trying to start the program will give an error that tells me wxbase294u_gcc_cl.dll is missing. I thought maybe its a debug library thing, so I set the build configs to release but still the same error.
My understanding was that Wxwidgets builds nativly to the OS so it shouldn't be dependant on such a large dll. The dll exists in the libs that was installed by Codlite, but the system does not seem to pick it up.
Am I supposed to build using VC++? not sure how to set that on the build settings.
I've been a WebApp guy for a long time and new to Cross-Platform devlopment, so help me out if I'm going the wrong way.
Thanks in advance.
The wxWidgets library code must be linked to your application code. This can be done in two ways: A) to use static libraries, which are linked to your application executable when it is built, or B) to use DLLs, which are linked to your application when it runs.
From your question, you have built your application to use DLLS.
You have two options to fix this problem. Easiest will be to copy the required DLLs into your application folder.
You can also change the codelite options to use wxWidgets static libraries - you will need a codelite expert to help you to do that.
I took a quick look at the codelite webpage. It does look like codelite uses wxWidgets DLLs by default. To change this, you will need to built wxWidgets the "DIY" way as described here but set the SHARED make option to 0