wasabii
commented
1 year ago Also fixes #258
Closed wasabii closed 1 year ago
wasabii
commented
1 year ago Also fixes #258
wasabii
commented
1 year ago Final status:
Only SunECC is enabled. Other libraries build. But their usage depends on platform specific class files being supported, which we do not yet have. This is a good start however.
This pull request introduces a new approach to some of the OpenJDK C code which has so far been rewritten as C#: stop and use the C.
Keeping up with JDK upgrades is difficult given the amount of backing C code which has been rewritten in C#. Keeping the exact operation of this code is a lot of manual effort. But it has thus far been difficult to consider what it would look like to actually just use the OpenJDK C as is.
This changes that.
A new SDK type is introduced: IKVM.Clang.SDK. This project type takes over for .vcxprojs, but focuses specifically on Clang. It introduces a method to do an Inner Build on TargetMachines, as a triplet given to Clang. This way a single project can target different machine configuration just like a .NET project can target different TFMs. A Visual Studio extension is published.
It follows the same basic Compile/Link path as most C build libraries. But, since Clang is a native cross compiler, it will allow us to introduce shared libraries built for each of the platforms we target. Three architectures on Linux, two on Windows, and two on OS X.
IKVM.Clang.SDK has been moved to the ikvm-clang GitHub project.
Three OpenJDK libraries have been ported that were previously unavailable and unworking in IKVM: j2pkcs11, sunec and sunmscapi. The first one provides PKCS11 support. The second provides Elliptic Curve Cryptography support. and the third provides MSCAPI on Windows. These are within projects named libj2pkcs11, libsunec and libsunmscapi. Only the SunEC classes have been enabled, but the native libraries for the others are successfully built.
Having a good cross compiler is just one part of the problem though. We also need to have the relevant headers and linking libraries available. Thus, this branch now requires that we have the Windows SDK present, the OS X SDK present, and a SDK-root for each of the relevant Linux targets.
If running the build on Windows, the native Windows SDK is used. If not however, the projects require a Windows SDK to be placed in /ext/ikvm-native-sdk/windows and the Mac OS X SDK in /ext/ikvm-native-sdk/macosx. These are available from the 'ikvm-native-sdk' GitHub project.
The Linux SDK is more complicated. We target 6 platforms presently: x86_64, arm and arm64 and the MUSL versions of each. A Linux sysroot with the appropriate libraries needs to be available for each at /ext/ikvm-native-sdk/linux. This SDK needs GCC 7.4 and GBLIC 2.27, as that is the closet set of targets required for the libraries we will be generating, as it's the lowest common denominator of .NET 3.1.
These SDK files are available in the ikvm-native-sdk project.
Two new props/targets files are also available to unify the settings between the various OpenJDK libraries: openjdk.lib.props and openjdk.lib.targets. Each extends the IKVM.Clang.Sdk project with common settings.
The user must have Clang installed locally. But he already needed this for IKVM.Runtime.JNI. It is likely we'll move the trampolines back to regular C now that we have a good framework for building regular C.
Additionally, since building for multiple platform is so time consuming, six other properties have been introduced throughout: SupportedRuntimes, EnabledRuntimes, SupportedToolRuntimes, EnabledToolRuntimes, SupportedImageRuntimes, EnabledImageRuntimes. Supported contains the full set of those RIDs we support and for which Restore runs. It should not be changed in the course of normal development. Enabled specifies that set that we will actually build. The user can edit Enabled* to build only for a specific platform, speeding up their build (dotnet build /p:EnabledRuntimes=win7-x64 for example).
Tests for ECC were reenabled.