Add compiler-rt settings to support baremetal builds and builtins #101
Conversation
This should improve the cross-compiler support, for example if we want to build for ARM. Part of ldc-developers#97.
|
Thank you, but I can’t check compilation yet: my computer (enterprise-grade server, hehe!) is not able to build biggest LLVM part due to random hangs. What about libunwind? This is important because ldc2 currently produces code what depends on it. |
|
Idea: maybe it is possible to create "pre-release" snap available from official snap storage? |
|
I'll test myself, but once it's done and merged, there will be a copy published to the |
|
Ok, thanks! |
Can you explain in more detail? In any case, that will be a separate PR, but happy to do it. |
|
I don't see how this would include the desired compiler-rt for an ancient ARM arch - the compiler-rt libs are built for the same (host) arch, so someone would have to build the LDC snap package for that arch (and then most likely only use the libs because a native compiler/LLVM is way too resource-hungry). I'd look into cross-compiling the compiler-rt libs alone, or use some prebuilt libs (e.g., package libclang-common for Debian) instead. I.e., not touch the snap package at all. |
I wasn't sure about that either. Is it a positive change in its own right, though? Or not worth keeping? |
Also this is one of most modern arch of MCUs.
I did not complete build process completely, but it seems to me that the build system builds all needed RT libraries and gives names to these libraries that includes name of architecture.
Is not have sence because it is almost impossible to build for architectures without this appropriate rt libraries. That is, if there is architecture supported by compiler, then for it you need a compiler runtime library for this architecture too.
This case is better, but won't there be inconspicuous inconsistencies in case of different versions of llvm backend?
Why is this so important? |
libunwind is part of LLVM project, it is library what provides support of exceptions handling. It is needed by result binaries if compiled without -betterC switch. Situation with this library is same as with compiler RTs - distros provide it only for host architectures. It is small and it is much easier to build it separately than a LLVM backend, but there is no particular reason not to put it into the bundle. |
|
If the snap size is become too large, it can be divided it into "standard" and "full". |
From the CMake output:
Not to mention that (compiling) the libs would obviously require a cross-compiler, and e.g. clang isn't built as part of building LLVM. |
yep :-( |
|
...Then for what are these lines was added? These targets also unusable without compiler RT. Each user will be forced to download and build LLVM with libraries to use it. |
|
Those lines enable the respective backends for codegen. And no, you don't need a whole LLVM for each target; for most targets, the builtins library from compiler-rt is optional too; for that ARM arch, you apparently need that lib when using 64 bit integers, and cross-compiling that lib with clang shouldn't be rocket science and not take too long to compile. |
|
@kinke perhaps it would be good to touch base some time on exactly what needs to be done to ensure the snap package can cross-compile effectively, and what is supported by the current official binary release packages downloadable from GitHub. That would include being clear about what needs to be in the package, and what should be assumed to be present on the host system where the cross-compile build is happening. (For example: the snap package already relies on an external Would you be happy to take some time to discuss this? This is an area where I feel inexperienced and would therefore welcome some clear guidance. No worries if you don't have the time or feel that it's my responsibility to RTFM a bit more ;-) I'm planning to be at DConf this year, so we could also consider making this a hackathon project there. |
Are 64bit integers is part of the language? In my opinion - yes. And this applies not only to ARM. For each architecture there are these nuances what covered by compiler RT. So I think it is need to provide this library as we provide compiler itself. And if some special case happens, then user will able disable this library just by exclude it from linking. |
AFAIK, the snap package should be identical to the official prebuilt packages in that regard (external C compiler + libs required too for Posix targets). The general approach is described here: https://wiki.dlang.org/Cross-compiling_with_LDC
Not really. ;) |
As I said, most other targets don't require the builtins lib; sometimes, required builtins (not just for 64/128-bit integers, but also soft-float implementations) are also provided by the C runtime. Edit: E.g., not required for Linux/AArch64, Android/ARMv7-A and Android/AArch64.
A normal x86 clang package doesn't ship with compiler-rt for the dozens of supported targets either, which would be required when cross-compiling to your ARM arch. And clang isn't a hobby project maintained by a couple of people. |
Yes, this seems like the right division. I think what I was implicitly wanting to know was whether anything extra had to be done to ensure druntime and phobos support for all those architectures (to the extent that the upstream code supports it). But I guess that doesn't need to be pre-bundled into the compiler package: instead the user can use
No worries. I think my roadmap from here is roughly as follows:
... and then return to cross-compiler concerns after this. Main thing is just to get a clear documentation of requirements out there. |
clang isn't a hobby project maintained by a couple of people => A normal x86 clang package doesn't ship with compiler-rt for the dozens of supported targets either, which would be required when cross-compiling to your ARM arch. In our D case we cannot afford to configure build for different architectures and distros and package files and separate RT libraries, etc, because community is too small for this. And this is an cause not to do for now as they do in clang. |
|
@denizzzka: I don't get your point and I'm not sure you got mine, but anyway: you're obviously welcome to figure out how to cross-compile the compiler-rt libraries (ideally the whole set, but the |
|
Closing as superseded by more recent changes to snap package (which now just wraps upstream builds). |
This should improve the cross-compiler support, for example if we want to build for ARM.
Part of #97.
@denizzzka FYI. Let's see if this addresses things.