GCC port of CoreCLR work has been going for some time now. This is the top level task to track the final goal.
A fork of the project is available here:
https://github.com/franksinankaya/coreclr/tree/uuid_rework_7
https://github.com/franksinankaya/coreclr/tree/gcc_port_${SOMESNAPSHOTDATE}
We are unable to complete this work until JIT work dotnet/runtime#12311 is done and we make the UUID solution nicer.
@janvorli : FYI
@am11 : can you please test this for the SmartOS distro?
@jkotas : see the test results per your request. Tested on ubuntu 16.04 using gcc 5.4.
Total tests run : 2510
Total passing tests: 2510
Total failed tests : 0
Total skipped tests: 0
I did see some more compilation errors with newer GCC versions like gcc 7.,x or gcc 8.x. Those issues are TBD at this moment.
I'm very happy to see work happening on this. I work with a platform (National Instruments RT Linux) which only has GCC, and I've been trying occasionally to see if it works.
My platform is also soft float ABI, and it looks like at one point that was being trialed so I'll be testing that as well.
@ThadHouse : glad to see more interest. Please post your findings/questions here. I'm willing to help.
I will do that. I'm currently trying the Yocto build (https://github.com/Tragetaschen/meta-aspnet) and modifying that for my platform, as I use that setup to currently build mono as well. Running into some issues based that build being mainly for arm, not armel, but I'm close.
I do have a question though. How does the armel JIT work? My platform has vfp3, so it does have floating point, but just uses the soft float ABI. Does the armel JIT do floating point operations in the FPU, and just use the ABI, or does it use completely software floating point?
@BruceForstall do you happen to know the answer?
The armel JIT does floating point in the FPU but uses the soft float ABI. So it's only an ABI change
@BruceForstall Thanks, that'll be cool to see if I can get it fully working. I've been using Mono, but getting .NET core will be a nice addition as well.
There's a lot of build setup thats hardcoded to do weird things in the armel build, so I'll try and create issues as I see them. Reported one to source-build, and with testing I'm sure I'll have a few more.
This task is compete as of this commit
https://github.com/dotnet/coreclr/pull/27487#event-2748534758
type
./build.sh -gcc
to build.
Tested on ubuntu 18.04
@jkotas : need some instructions for how to set up a CI/CD with ubuntu.
For Windows, the latest greatest version of VS (2019) is used in CI as soon as it came out. OTOH, Unix builds are using old clang/libc (for wider distribution support).
It would save some future effort (and persist the effort already put in), if a CI job in upcoming runtime GitHub repo is dedicated to validate build against latest Clang and latest GCC.
For GCC, there is official docker hub channel https://hub.docker.com/_/gcc, with latest tag available: docker run -it gcc:latest. For clang we can set up our own using the method described here: http://apt.llvm.org/.
I think we should do both. Start with most used systems like Ubuntu 18.04. Then, spread the coverage.
Unix builds are using old clang
This is not true anymore, last week I've merged a change that switches use to clang 9 except for Alpine, where we are still stuck with clang 5.
Great, thanks for the update @janvorli.
For Alpine, we have clang v8 available in 3.10 repo https://pkgs.alpinelinux.org/packages?name=clang&branch=v3.10&arch=x86_64. And with apk add clang --no-cache -X http://dl-cdn.alpinelinux.org/alpine/edge/main has v9 available.
And with
apk add clang --no-cache -X http://dl-cdn.alpinelinux.org/alpine/edge/mainhas v9 available.
Unfortunately, it doesn't work on Alpine 3.9 that we currently use for building stuff. I've tried that over the weekend. It installs, but it fails at runtime due to two missing exports from stdlibc++.
Most helpful comment
This task is compete as of this commit
https://github.com/dotnet/coreclr/pull/27487#event-2748534758
type
./build.sh -gcc
to build.
Tested on ubuntu 18.04