Foreign target toolchain compilation passes -nodefaultrpaths to Clang when linking libcc1
#18
Comments
winterqt
changed the title
-nodefaultrpaths to Clang when linking libcc1-nodefaultrpaths to Clang when linking libcc1
There is currently an issue when compiling a foreign toolchain on aarch64-darwin [0]. Until this is fixed, let's use GCC 11 in this scenario, where it works. [0]: iains/gcc-12-branch#18
|
so you are building a cross from arm64-darwin to avr? actually, the unpatched GCC-12 branch should work to build cross-compilers from arm64-darwin to some other target (the host-side stuff was committed upstream already). I will look into what's needed to avoid this issue. |
Correct, yes.
I see, would we be better off not applying the patch in the case where only host Darwin is needed, then? I'll test this now. |
|
It would be better to have a consistent branch that works for both native and cross-compilers (I have already tested that the branch builds a native compiler on Linux, but I had not tested a cross from Darwin => something else). In the short-term, yes you can try upstream - but there are non-arm64 additions too so this needs to be fixed. I have not had any time recently to work on upstreaming more of this ... |
|
BTW, the general recommendation (and a hard requirement when building Ada) would be: 1/ bootstrap a native GCC with the sources you want to use This is because the host compiler (in this case clang, but it could be some older GCC too, same applies) does not implement the same set of builtins etc. that GCC does and you do not have the bootstrap step to isolate your intended cross from that. |
It seems that the patchset we apply to get some fixes for aarch64-darwin support [0] breaks in unexpected ways when compiling a foreign toolchain. Luckily, according to the branch's author [1], the patchset isn't required for merely using aarch64-darwin as a build system, so let's only apply it when hostPlatform == aarch64-darwin to fix cross. [0]: iains/gcc-12-branch#18 [1]: iains/gcc-12-branch#18 (comment)
It seems that the patchset we apply to get some fixes for aarch64-darwin support [0] breaks in unexpected ways when compiling a foreign toolchain [1]. Luckily, according to the branch's author [2], the patchset isn't required for merely using aarch64-darwin as a build system, so let's only apply it when hostPlatform == aarch64-darwin to fix cross. [0]: https://github.com/iains/gcc-12-branch [1]: iains/gcc-12-branch#18 [2]: iains/gcc-12-branch#18 (comment)
It seems that the patchset we apply to get some fixes for aarch64-darwin support [0] breaks in unexpected ways when compiling a foreign toolchain [1]. Luckily, according to the branch's author, the patchset isn't required for merely using aarch64-darwin as the build system [2], so let's only apply it when hostPlatform == aarch64-darwin to fix cross. [0]: https://github.com/iains/gcc-12-branch [1]: iains/gcc-12-branch#18 [2]: iains/gcc-12-branch#18 (comment)
|
This problem seems to also affect Gentoo Prefix's bootstrapping procedure on macOS, during the stage2 bootstarp to build GCC 12.2, |
|
you say "bootstrapping" - but I am surprised (because libcc1 is not built at stage 1 so it should always be built with GCC for a native (bootstrapped) build). Please can you be more specific about what build you are performing and with the configure line? |
|
No idea, I'm still investigating the problem. I'll report back if I find anything. |
|
BTW, there is a potential of terminology confusion. The "stage2" I mentioned refers to the Gentoo "stage2" bootstrap, not the GCC "stage2" bootstrap. Like GCC, Gentoo itself uses a similar strategy to install itself on a foreign system. During stage1, a minimal set of tools is built outside Gentoo, these tools are used together with host tools to create a base environment. During stage2, basic packages are rebuilt and installed within Gentoo, and during stage3 the system is also rebuilt globally. If I get it correctly, during Gentoo stage1 and stage2 bootstrap, GCC's own 3-stage bootstrap is disabled, only the first bootstrap pass is performed until Gentoo stage3. I'm still not sure if it's a problem in the Gentoo bootstrap script or a problem in GCC Darwin. But the symptom is similar, so at least there's a direction for investigating it... |
|
Are you trying to build a cross-compiler from Linux to arm64-darwin? (if so, then that seems a possibly slightly different case, but plausibly affected) .. if yes, please post the configure line and I'll add that to the cases to investigate - unfortunately the short-term workaround will be no good for a cross from Linux targeting arm64 Darwin (you absolutely need the branches here to target arm64 darwin).. If you are targeting x86_64 Darwin .. then you can use the unpatched release branch. |
|
I have a similar issue on darwin-arm64 branch. This was the error. I ran the below. |
|
Hmmm... as noted unless you are building a cross-compiler libcc1 should be built with GCC and therefore it should understand the options. @fxcoudert ... I have some dim memory of clang being used to link GCC output .. could this be related? (I am wondering why there is suddenly a bunch of similar reports) :) clearly there is a problem to be fixed - but at the moment I have not enough information to narrow down what we want to work (it might be we have to detect whether the compiler supports the options in the libcc1 configure ... ) |
Yes, I've now determined the problem is caused when clang is used to link GCC output. So this is not a GCC issue, but a downstream issue, though it's triggered by the upstream change. Basically, although it's not guaranteed, passing GCC output into clang actually worked in GCC 12.1.0 and earlier versions, before the incompatible linker options As a result, some non-standard build procedures, whether unintentionally (probably @ProgramComputer's case) or intentionally (in the case of Gentoo prefix, it's used to simplify the process of building the toolchain during the early stage in a Gentoo installation), as the developers says: So the lesson for our downstream users is: after GCC 12.2.0, GCC must be used all the time for linking and it should not be mixed with other compilers such as Apple's LLVM/clang. Though, for Gentoo, I think I'm going to use the workaround of disabling
No, it's not a cross-compile. The actual reason of this error has been explained above. |
|
It is probably a bit strong to say " after GCC 12.2.0, GCC must be used all the time for linking and it should not be mixed with others" we can be more flexible with some thinking, I am sure. firstly, IMO we can adjust the configuration of libcc1 to determine if the options are supported and not use them if so (with the assumption that clang will not add the default stuff anyway so that is a NOP there anyway). In this specific case OTOH, using clang as the linker is only going to work for arbitrary exes if it adds the runpaths as GCC does - otherwise you are forced to have a non-relocatable installation and to re-write the runtime library paths as described below. That's kinda sad, in a way, macOS has generally the policy that the user can drag and drop stuff around.... So, depending on your distribution, using fixed paths might/might not be problematic. AFAIU, the home-brew mechanism:
I (more than) half expect you to run into difficulties on modern macOS (10.11+) without the @rpaths used at build time. I agree that making a fixed install is the path of least resistance, but would still aim to make GCC a good macOS citizen w.r.t to installation in non-super-user locations and by drag and drop. |
In the particular case of installing Gentoo Prefix, the hardcoded But I fully agree, hardcoding |
|
hmm, shouldn't accepting fixed location during (gcc) stage 1 of bootstrap be OK, since later stages should compile a driver that acts well enough to handle rpaths correctly? stage1 would get thrown out anyway, and not be relocated during a single build |
|
an aside (for the Linux folks on this thread).... You need to remember that macOS (from OSX 10.0) has "two level" library names. This means that the library name [from 10.0...10.4, at least] always includes its runpath + it's name (/path/to/libname.dylib). This, in turn, gets built into depending DSOs so that a separate runpath is not needed. After 10.4, there is a second option where the library can be named To work around the fixed runpath (original model) we used to use After 10.11, Apple altered a lot of the system infrastructure such that i tried a bunch of ways around this, but in the end the best solution is to shift to using the second approved runpath mechanism - since that allows us to build libraries that are neutral about their install position. We then ensure that the depending DSOs get runpaths suitable for their use (in the build dirs during build, or in the installed position after installation). This is done by the driver providing the runpaths based on where it is ... So stage1 .. or N is not significant - we always use the newly-built GCC to build target libs (even for a cross-compiler) We want to suppress addition of build-time runpaths into built libs that have dependent GCC DSOs (which is what one option is about - the other is about use of emulated TLS). So, in general, clang will not be a suitable [automatic] link mechanism for GCC when the ===
If one wants to support built applications that can be dragged & dropped or otherwise relocated by the end user, then HTH explanation-wise. |
It seems that the patchset we apply to get some fixes for aarch64-darwin support [0] breaks in unexpected ways when compiling a foreign toolchain [1]. Luckily, according to the branch's author, the patchset isn't required for merely using aarch64-darwin as the build system [2], so let's only apply it when hostPlatform == aarch64-darwin to fix cross. [0]: https://github.com/iains/gcc-12-branch [1]: iains/gcc-12-branch#18 [2]: iains/gcc-12-branch#18 (comment)
It seems that the patchset we apply to get some fixes for aarch64-darwin support [0] breaks in unexpected ways when compiling a foreign toolchain [1]. Luckily, according to the branch's author, the patchset isn't required for merely using aarch64-darwin as the build system [2], so let's only apply it when hostPlatform == aarch64-darwin to fix cross. [0]: https://github.com/iains/gcc-12-branch [1]: iains/gcc-12-branch#18 [2]: iains/gcc-12-branch#18 (comment)
It also breaks cross compiler builds when the build compiler does not support the -nodefaultpaths option (etc.) This is issue #18 on the arm64 gcc-12 branch. Signed-off-by: Iain Sandoe <iain@sandoe.co.uk> libcc1/ChangeLog: * Makefile.am: Do not use @rpath for libcc1. * Makefile.in: Regnerate. * configure: Regenerate. * configure.ac: Do not use @rpath for libcc1.
|
should be fixed in 12.3-darwin-r0 |
It seems that the patchset we apply to get some fixes for aarch64-darwin support [0] breaks in unexpected ways when compiling a foreign toolchain [1]. Luckily, according to the branch's author, the patchset isn't required for merely using aarch64-darwin as the build system [2], so let's only apply it when hostPlatform == aarch64-darwin to fix cross. [0]: https://github.com/iains/gcc-12-branch [1]: iains/gcc-12-branch#18 [2]: iains/gcc-12-branch#18 (comment)
When building GCC for a foreign target platform on aarch64-darwin (e.g.
avr), the following erroneous command is run:This happens because
clang++isn't aware of the-nodefaultrpathsoption added in this branch. This does not happen during native toolchain compilation, or on (probably the most notable) the GCC 11 branch.The text was updated successfully, but these errors were encountered: