Closed ilg-ul closed 2 years ago
BTW, g++-xbb
is a GCC 11.1 built from your sources, which seems ok.
which source code are you using? I have fixed the cross-compilation on master, but that has not been back-ported to earlier branches - however, I would expect that my 10.3 source (https://github.com/iains/gcc-10-branch/tree/gcc-10-3-apple-si) would build a cross-compiler;
The official gcc-arm-none-eabi-10.3-2021.10-src.tar.bz2
source tarball.
ah - well, no, that would not be expected to work - there are a few patches needed to enable host-side support (even to build a cross-compiler). If you need a later source than 10.3 release, then let me know and I'll see what can be done - but applying those changes "upstream" is not even certain - this is a new port, so back ports are not "regression or bug fixes".
... however, I will keep a 10.x and 11.x branch going ;)
Unfortunately I'm stuck with using exactly the same releases as Arm does, so for now it is that archive plus some possible patches.
I tried to figure out the differences by taking a look at your branch, but I would appreciate any hints, since at first sight I did not find anything related to the host hooks.
I'll try and isolate what you need - later today, hopefully.
Thank you very much!
completely untested 8 patches here https://github.com/iains/gcc-10-branch/tree/gcc-10-aarch64-host
you should add "--disable-libstdcxx-pch" to the configure since I have not added any patches to that to deal with disabling / working round PCH issues (PCH will not work with the patch set above).
====
There is stuff still 'in flux' as to what will be applied to master - it's better not to back port speculative fixes unless there's no choice (so I'm waiting - unless/until there is a branch release imminent)
I'll try this shortly, thank you. Host only is enough for now.
It took me a bit to manage those patches, since the repository used by Arm is not public, and I had to recreate it from the provided archive. :-(
Anyway, I cherry picked your 8 commits, prepared a patch, and added it to my build scripts
The configure step reported Using host-darwin.o host-aarch64-darwin.o for host machine hooks., the build started, but finally failed:
ar: host-aarch64-darwin.o: No such file or directory
make[1]: *** [Makefile:2045: libbackend.a] Error 1
rm gfdl.pod gcc.pod gcov-dump.pod gcov-tool.pod fsf-funding.pod gpl.pod cpp.pod gcov.pod lto-dump.pod
make[1]: Leaving directory '/Users/ilg/Work/arm-none-eabi-gcc-10.3.1-2.3/darwin-arm64/build/gcc-10.3.1-first/gcc'
make: *** [Makefile:4371: all-gcc] Error 2
The reason is that the host-aarch64-darwin.c
file is not present.
Is there any other branch where I should search for this file?
[Darwin, aarch64 : Initial support for the self-host driver. 3dc354d83366 Iain Sandoe iain@sandoe.co.uk 17 Nov 2021 at 13:08] (https://github.com/iains/gcc-10-branch/commit/3dc354d833663e52c1a9e20827925aeab1ea2c21)
Should have that source file in it ?
I probably messed something, I'll redo the patches.
It took me a bit to manage those patches, since the repository used by Arm is not public, and I had to recreate it from the provided archive. :-(
It's usually easiest to create a new git repo with the tarball .. and then add a new point for each succeeding one.
you can export the patch series using 'git format-patch xxx...yyy -o series/ and then apply each one in turn with patch -p1 <series/0xxxx.....
but that has 0 change control ;)
It took me a bit to manage those patches, since the repository used by Arm is not public, and I had to recreate it from the provided archive. :-(
It's usually easiest to create a new git repo with the tarball .. and then add a new point for each succeeding one.
one can add a remote without shared history - you might need to override something depending on the git version - but that also works providing, of course, that the sources really are from the same origin.
Right, there is a lot of room for improvements in the way I manage patches :-(
At the second attempt, the development version of the build completed successfully, and the minimalistic tests passed.
I restarted the script to get the production (multi-lib) version; it takes several hours, I'll know tomorrow morning how it went.
Do you think the same patches will also work on a bit older 10.2.0? I have to port the RISC-V toolchain too, and it is based on a patched GCC 10.2.0.
no; I am sure that you will need some more patches - the underlying changes for Darwin2x were applied between 10.2 and 10.3 along with some other base changes the port,
at least these (possibly others) from the GCC 10 branch [reverse order as from git log --online - i.e. apply bottom to top] :
093788fb9683 Darwin : Fix out-of-bounds access to df_regs_ever_live.
9982ca0f0e3c Darwin : Simplify headers.
2dc332f7ce48 Darwin : Adjust defaults for current bootstrap constraints.
aa55f33e6cb5 Darwin: Guard two macros in darwin.h.
df11e89be569 Darwin : Avoid a C++ ODR violation seen with LTO.
08d4e37c91b4 Darwin : Begin rework of zero-fill sections.
dc734dad7aee Darwin : Update libc function availability.
a996d8d7a8d0 Darwin: Handle poly_int machine_modes.
c85bc938ccf7 Darwin : Update libtool and dependencies for Darwin20 [PR97865]
7b19b6b15368 Darwin, libsanitizer : Support libsanitizer for x86_64-darwin20.
82abd13fb66e Darwin : Adjust handling of MACOSX_DEPLOYMENT_TARGET for macOS 11.
f5ee16a0d8e3 Darwin : Update the kernel version to macOS version mapping.
24957662c670 Darwin: Darwin 20 is to be macOS 11 (Big Sur).
d0bae0b218d5 Darwin: Adjust the PCH area to allow for 16384byte page size.
You can give it a try - but I don't even know if that series will apply without fixing up individual changes.
I see. I can already build it on Intel 11.6, the problem is only the Arm port.
However the configuration for 11.6 on unpatched 10.2 would still be missing those patches - not sure of the exact impact without more study, perhaps it's not significant for host-only code.
Of course, you can always try with only the second set on aarch64... but I suspect that the version reported by the kernel will cause problems with the driver code.
Since the arm-none-eabi-gcc
build passed, I'll close this issue.
For the riscv-none-embed-gcc
build, I opened a separate ticket (#51).
I know that this project focuses on native GCC, but I guess some of your experience might help for cross-compilers too.
I'm trying to compile the GNU Arm Embedded Toolchain on a new Mac, and the build went up to:
I am not very familiar with the GCC internals, but it looks like some platform specific code is missing.
The compiler is expected to generate bare-metal code, so the difficult security issues which you have in the native compiler should not face here, the main challenge would be to build the compiler.
Are there any (reasonably complex) patches that can be applied for this?
Any advice on how to proceed?