Initial Linux support

[Dadoum]

I just adapted part of XNU headers in the folder. Hopefully I didn't break anything on macOS.

Addresses part of #11

[p-x9]

Thanks.

As for MachOImage, I don't think all the features are available on Linux.
Therefore, I was thinking that everything could be wrapped up in #if canImport(Darwin).

Similar problems also occurred when supporting Linux with ELFKit, but it seems that for some header files it is necessary to use #if !__has_include to avoid duplicate definitions.
https://github.com/p-x9/ELFKit/blob/ca073217cfc55921a33f01aa2360b56bcb78db66/Sources/ELFKitC/include/elf32.h#L37

[Dadoum]

As for MachOImage, I don't think all the features are available on Linux. Therefore, I was thinking that everything could be wrapped up in #if canImport(Darwin).

Since they compile, they can be useful to make a mach-o loader on Linux so I think it's okay to leave them enabled.

Similar problems also occurred when supporting Linux with ELFKit, but it seems that for some header files it is necessary to use #if !__has_include to avoid duplicate definitions. https://github.com/p-x9/ELFKit/blob/ca073217cfc55921a33f01aa2360b56bcb78db66/Sources/ELFKitC/include/elf32.h#L37

Now working on that (I also noticed the use of Apple's Crypto library bumps the requirements from macOS 10.13 to 10.15, is that okay for you?).

[p-x9]

Thanks @Dadoum .

Since they compile, they can be useful to make a mach-o loader on Linux so I think it's okay to leave them enabled.

That's true.

Now working on that (I also noticed the use of Apple's Crypto library bumps the requirements from macOS 10.13 to 10.15, is that okay for you?).

I thought the way it was written when using Apple's Crypto library was simpler and better than the current implementation, so the required OS version bump was not a problem for me.

[p-x9]

👍

[p-x9]

Hello, @Dadoum
I tried to build on macOS and I got some errors related to include in the header file.
I have made some fixes, can I push some additional commits to this pull request?
(I am using the virtual environment Ubuntu 22.04 for testing in a Linux environment.)

[Dadoum]

Yes you can. I tried to work with the updated branch but my swift compiler now crashes when trying to compile it (I need to find a fix, or to wait for a swift update for fedora)

[p-x9]

It was not possible to push additional commits to this pull request.
(This may be due to the fact that it is the main branch.)

In my environment, I was able to build on both MacOS and Ubuntu with the following changes.

0001-Move-c-headers-for-linux-platforms.patch
0001-Update-supported-version-of-platforms.patch
0001-Do-not-run-MachOPrintTests-in-a-Linux-environment.patch

[Dadoum]

I can't test it unfortunately because I can't build PrebuiltLoader.swift unfortunately. I tried on Swift 5 and 6 on my main Fedora machine. Will commit your changes though.

For the record, here is a snippet of what outputs Swift 6 experimental dev version from Ubuntu on my computer:

2.      Compiling with effective version 5.10
3.      While walking into 'prebuilt_loader' (in module 'MachOKitC')
4.      While verifying VarDecl 'isPrebuilt' (in module 'MachOKitC')
 #0 0x000055c6ec6f3f67 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/dadoum/KDLs/swift-DEVELOPMENT-SNAPSHOT-2024-09-11-a-ubuntu20.04/usr/bin/swift-frontend+0x886ef67)
 #1 0x000055c6ec6f1c6e llvm::sys::RunSignalHandlers() (/home/dadoum/KDLs/swift-DEVELOPMENT-SNAPSHOT-2024-09-11-a-ubuntu20.04/usr/bin/swift-frontend+0x886cc6e)
 #2 0x000055c6ec6f45df SignalHandler(int) Signals.cpp:0:0
 #3 0x00007f315f64fd00 __restore_rt (/lib64/libc.so.6+0x40d00)
 #4 0x00007f315f6a84a4 __pthread_kill_implementation (/lib64/libc.so.6+0x994a4)
 #5 0x00007f315f64fc4e gsignal (/lib64/libc.so.6+0x40c4e)
 #6 0x00007f315f637902 abort (/lib64/libc.so.6+0x28902)
 #7 0x000055c6e74802ec (anonymous namespace)::Verifier::verifyChecked(swift::AbstractStorageDecl*) ASTVerifier.cpp:0:0
 #8 0x000055c6e747fc41 (anonymous namespace)::Verifier::verifyChecked(swift::VarDecl*) ASTVerifier.cpp:0:0
 #9 0x000055c6e746ad38 (anonymous namespace)::Verifier::walkToDeclPost(swift::Decl*) ASTVerifier.cpp:0:0
#10 0x000055c6e74819ba (anonymous namespace)::Traversal::doIt(swift::Decl*) ASTWalker.cpp:0:0
#11 0x000055c6e7485daf (anonymous namespace)::Traversal::visitNominalTypeDecl(swift::NominalTypeDecl*) ASTWalker.cpp:0:0
#12 0x000055c6e7484bd9 (anonymous namespace)::Traversal::visit(swift::Decl*) ASTWalker.cpp:0:0
#13 0x000055c6e74819aa (anonymous namespace)::Traversal::doIt(swift::Decl*) ASTWalker.cpp:0:0

[Dadoum]

It's due to the bitfields used in the structure!