I am writing some cross platform C++ libraries requiring platforms specific implementations. To compile a library for a specific platform/compiler/etc, one has to detected the platform/compiler in the first place at compile time and based on C preprocessor macros.
I found two libraries so far:
POSH
Predef
Are there any other ones ? I am especially interested in the ones that can detect iOS/Android platforms, Clang compiler for instance.
After some additional searching, I have not found any new ones.
Related
I want to create a Kotlin project compatible with Android and Desktop. This project needs to bind to a C library.
The way I understand it, I should create a Kotlin multiplatform project, and have a common code which wraps the C library using JNI.
However, Kotlin/Native allows a way easier interop with C libraries, so I'd like to use that. But it seems like Kotlin/Native is a platform (equal to eg jvm or android), so it can't be used as a common code.
Is there a way to do what I want? I couldn't find any simple example doing that.
If that's not possible, why? Kotlin/Native is able to target desktop and android platforms. If it's possible to use Kotlin/Native on Android, why is it impossible to use a Kotlin/Native library from a "normal" desktop/android project?
This should be possible with Kotlin Multiplatform, by having a native target.
See https://kotlinlang.org/docs/native-app-with-c-and-libcurl.html#create-a-definition-file
Kotlin/Native helps consume standard C libraries, opening up an entire ecosystem of functionality that exists for pretty much anything you may need. Kotlin/Native is already shipped with a set of prebuilt platform libraries, which provide some additional common functionality to the standard library.
UPDATE:
"common" code in Kotlin Multiplatform under the hood either:
a) has platform-agnostic Kotlin code or
b) uses expect/actual to define platform abstractions
(AFAIK)
Since a C library isn't a), you'll have to define the actual platform definitions, ending up with JNI.
TL;DR KMP isn't suitable for what you're trying to do
I saw the two projects are quite related, but what are the differences between them? The official webpage doesn't tell much about it.
I know that ABI (Application Binary Interface) is used to provide low-level binary interface among different platforms. So is libc++abi used to provide different implementations for different platforms, and general interface for libc++?
Would be better go give some specific example, e.g. what are included in libc++abi and what in libc++.
Thanks.
The Application Binary Interface, or ABI for short, is intended to provide certain low level functions from which to build the C++ standard library. It is a supporting library that is a separate component from the actual standard library. Along with libcxxabi, you may also come across Pathscale's libcxxrt or GCC's libsupcxx.
On the other hand, libc++ is an implementation of the C++ standard library that can be built using either of the 3 mentioned ABIs.
I'd like to ask if gnustep's toolchain is appropriate for netbsd development where one'd normally use plain C. I'm interested in the benefits of Obj-C only with basic APIs like NSObject's reference counting and dynamic stuff.
My question is twofold:
is gcc's Obj-C ABI compatible with gcc's C ABI? so that I can use regular C libraries
is Obj-C's runtime layer good to go where netbsd targets embedded?
Thank you in advance!
is gcc's Obj-C ABI compatible with gcc's C ABI? so that I can use regular C libraries?
This has nothing to do with the ABI at first glance. Objective-C is a strict superset of C, so it's true on every platform that you can use C code with Objective-C code. You can even call Objective-C methods from plain C code using the Objective-C runtime library.
is Obj-C's runtime layer good to go where netbsd targets embedded?
I don't exactly see what the question is here. Are you asking whether it is possible to port GNUstep to embedded platforms? If so, I'd say yes, it should normally be possible (with the appropriate constraints of an embedded system), but in my opinion, it's too heavyweight for embedded development.
If you aren't interested by AppKit, you may also take a look at https://webkeks.org/objfw/.
Runtimes may contain assembly bits that you will want to verify that they will actually work on specific CPU type. Old Foundation library like libFoundation may also suite your needs. If you want to use thing like Objective-C++ or Objective-C 2.0, I'd recommend clang instead of gcc.
Suppose I have a software and I want to make cross-plataform plugins. You compile the plugin for a virtual machine, and any platform running my software would be able to run this code.
I am wondering if it is possible to use LLVM interpreter and bytecode for this purpose. Also, I am wondering if does make sense using LLVM for this purpose instead of something else, i.e. is it what LLVM was made for?
I'm not sure that LLVM was designed for it. However, I doubt there is anything that hasn't been done using LLVM1
Other virtual-machines based script engines are specifically created for the job:
LUA is very popular
Wikipedia lists some other Extension/embeddable languages under the Scripting language entry
If you're looking for embeddable virtual machines:
IKVM supports embedding JVM and CLR in a bridged mode (interoperable)
Parrot supports embedding (and includes a Python interpreter; mind you, you can just run python bytecode images)
Perl has similar architecture and supports embedding
Javascript supports embedding (not sure about the architecture of v8, but I guess it would use a virtual machine)
Mono's CLR engine supports embedding: http://www.mono-project.com/Embedding_Mono
1 including compiling c++ information to javascript to run in your browser...
There is VMIR (https://github.com/andoma/vmir) which is a LLVM bitcode interpreter / JIT engine that's intended to be embedded into other apps.
Disclaimer: I'm the author of it and it's still work-in-progress but works reasonable well.
In theory, there exist a limited subset of LLVM IR which can be portable across various platforms. You shall not specify alignments, you shall not bitcast pointers to integral types, you must avoid intrinsics, etc. Which means - you can't immediately use a code generated by a stock C compiler (llvm-gcc, Clang, whatever), unless you specify a limited target for it and implement sanitising LLVM passes. Another issue is that the bitcode format from different LLVM versions is not guaranteed to be compatible.
In practice, I would not go there. Mono is a reasonably small, embeddable, fast VM, and all the .NET stack of tools is available for it. VM itself is pretty low-level (as long as you do not care about the verifyability).
LLVM includes an interpreter, so if you can build this interpreter for your target platforms, you can then evaluate LLVM bitcode on the fly.
It's apparently not so fast though.
In their classic discussion (that you do not want to miss if you're a fan of open source, LLVM, compilers) about LLVM vs libJIT, that has happened long before LLVM became famous and established, the author of libJIT Rhys Weatherley raised this particular issue, he stated that LLVM is not suitable to be embedded, while Chris Lattner, the author of LLVM stated that otherwise, it is modular and you can use it in any possible fashion including embedding only the parts you need.
I was looking at doxygene and I noticed that its output for objective-C is less than optimal, so I was looking at doxygene's internals(in which all syntax analyzers consolidated into a huge blob), and then I decided that it was going to take a lot of work just to figure out where to begin with that.
So I thought, ok let's start by creating a dictionary/tree from an objective-c source file which it seems Xcode does already(because symbols are search able). And it seems to use LLVM"clang" somehow. Does anyone know how I can invoke "clang" to return a structure of the symbols in a project/document?
Xcode doesn't directly use the "clang++" binary for this purpose. The clang++ binary is actually a very small wrapper around the Clang C++ libraries. Xcode uses libclang (a C wrapper around the C++ libraries) for its C++ parsing needs.
Thus, to get the information you want, you will need to use libclang. On this page are the slides and video of a presentation Doug Gregor (the main developer of Clang) gave at the 2010 dev meeting entitled "libclang: Thinking Beyond the Compiler".
Many people in the clang community have expressed interest in replacing Doxygen's parser with clang. So you are not alone. However, I believe it is not a small project.