Stage 2 failure building generator #3
Comments
|
I recall earlier Xcode 15 having quite a few problems (mostly with the new linker) that we worked around by configuring to use "ld-classic" .. If possible, update to Xcode 15.3 which is known to work (and has quite a few wrinkles ironed out). If that is not possible, then perhaps we can find a configure recipe that will use the 'classic' linker. |
|
Our problem with 15.3 (well, CLT 15.3) is that it doesn’t provide Since this compiler is being provided to users, would it make sense to go for as early an XC version as actually builds the compiler? I’m trying XC 15.1 on Github as I write ... |
|
If you are trying to have one build that runs using several different XC installs, we are going to need to be careful - the compiler configuration determines the capabilities of the support toolchain (as, ld, dsymutil) and adjusts accordingly. Similarly, the SDK in use is relevant (since some of the SDKs require special handling). If you are building the compiler, and providing it as a built item - then perhaps building m4 is not the end of the world. For the record, I build GMP et. al as "in-tree" sources - they are bootrapped along with the compiler and I have not run into trouble with XC15.1b. As noted CLT 15.0 did have (dyld-linker) problems that are show-stoppers .. so .. you need to stop and take pause about what you want to offer and how to communicate that to your users. edit: note that generally speaking toolchains are considered to consist of all the items in use - compiler, linker, assembler, debug linker. Xcode does not try to marry an arbitrary clang version with any arbitrary linker .. so perhaps you can constrain what you offer without being seen as providing a poor solution? |
|
We’re building the compiler, and providing it to our users as a built item. I build gmp etc in-tree, my colleagues out-of-tree, for reasons. Anyway, I ran I ran on Github with XC 15.1 and 15.3 - no change. I noticed that using their successful x86_64 build of GCC 14.1 to compile this trampoline-using program generated a reference to in spite of the fact that it didn’t need to, because of linking with My build of GCC 14.1.0 (using the FSF release) didn’t. I think this might be down to a specs difference: theirs has and mine has (the difference is that theirs has Why that should result in their failure to build the aarch64 compiler I don’t know. I found some interaction between |
|
getting the specs right for the various permutations of Darwin's support for DYLD_LIBRARY_PATH has been somewhat of a labour. Since (at least what I infer from your report) it seems that you are using different versions/branches/patches (?) it's very hard for me to figure out what might be wrong. Really, the recommendation (for people who are not using homebrew, macports etc.) would be to use the branch(es) here - and if something does not work properly (or how you need it to) report issues so we can fix (or work around) them .. once we diverge significantly it's outside of what my meagre resources can handle :) and specs are a powerful tool .. |
|
Both I and my colleagues are using
When run on Github, the compiler build crashes with the failure to run the When run locally, the compiler build succeeds. I’ve tried XC 15.1 locally and on Github, no change. What I’m going to do next (after family commitments) is to compare the build logs. After that, I’ll try to find why my own set of build scripts (again, using unpatched |
That the specs are different is, in that case, pretty odd. Having said that the configuration does adjust to the capabilities of the host system - including to whatever is detected in terms of linker capabilities***
On the GH/colleague's version this is a separate step - where you (and I) usually just build them in-tree? (not that I expect that to make the difference).
Can we get the output of
no change == builds locally, fails on GH?
That could be quite an involved project - now I know you are starting from the same point - the thing is to figure out why the configure / build thinks that there's a difference. === *** some configure functionalities depend on the installed utilities (e.g. Those are areas where there could be deviation between the environments. I am understanding (hopefully) that the failing get_il-main is built by the stage #1 compiler (and not the host/bootstrap one)? |
|
if it is possible, please could you post the output of:
from the failing case .. .. IIUC, this is a $build tool (i.e. intended to run on the $build system which can be different from the $host one) and should be being built with the bootstrap/build-system compiler. edit: there are several Ada build-time tools. |
|
please also post your configure lines (for both cases). I just took a look at my gcc-14.1 build and get_il-main seems to be correctly built with the bootstrap/build-system compiler at each stage. |
|
I’m going to be away for a few days, but in the mean time
(the LC_RPATH refers to the host compiler).
(i.o.w no LC_RPATH entries at all). |
Yes, it’s the one built in stage 2 by the compiler that was built by the host compiler in stage 1 |
but I don't think that is right .. it is an exe to run on the build system - it should be built with XXX_FOR_BUILD (which is effectively XXX_FOR_HOST when bootstrapping). I will have to see from your configure lines what is confusing the ada build into using the stageN compiler to build for $build (it does not happen for my configure lines, that exe is built with the bootstrap/build-system compiler in each stage) |
|
BTW : https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79885 is the reason that I avoid --with-build-sysroot= ... I see both configure lines have a bunch of (what I believe are) unnecessary configure flags - it is important to be very clear about why any non-standard flag is added - the configure script is supposed to get it right for the platform; if it is failing we should fix it and then remove any work-around. |
|
I would also suggest :
I like your creative specs for the sysroot; but what would be better is an upstream BZ that says what the problem is so that, maybe, we can find a more efficient solution than checking for each invocation. You are on different OS versions, it seems .. although TBH, I'd hope that does not affect things too much. Are you using the singe additional fix posted to the gcc-14-1-darwin branch? that could, potentially fix issues with mishandling the SDK (although I'd expect a different kind of fail from it .. so maybe not relevant). edit2: note also that gnatmake et. al. do not accept a --sysroot option .. so that has to be done at a lower level (hopefully, it is working OK). |
|
I was wrong about the compiler used to build I tried the 14.1.1 patch, no change. I’ve done my local builds in a new account running
GH, Mine, The reason for the different specs is almost certainly that I In both GH and local, the second build of otool -Lotool -l gen_il-main.. is the first ... where it’s trying to pick it up from |
That is not correct, indeed, @rpath is needed for correct operation on any OS >= 10.11 (which includes 12) .. that is a bug - please could you try with MACOSX_DEPLOYMENT_TARGET=12.0 to see if that helps narrow down the issue. I'll look at the rest of the report later / tomorrow. |
yes that allows libraries to find dependents that are co-installed (actually not necessary for libgcc_s.1.1.dylib since it's a leaf - but also should be harmless.
this looks right and, for my builds (the use of GCC-11.4 c.f. 13.2 should be irrelevant): So .. as you can see, the $build system compiler is used in each case and correctly adds its rpaths.
Certainly, this is wrong - and, I think, is the result of disabling darwin-at-rpath (although how that is affecting what the $build system compiler is doing is 'interesting'. We need to figure out why but, in the short-term how about confirming this with
|
|
hmmm I also wonder if this is an odd interaction between gnatmake and the external compiler. supposing that the gnatmake used to build gen_il is not the $build one, but happens to be the "just built" one .. then perhaps it is passing inappropriate flags to the called GCC version (which is $build) ... it has been the case in the past that unguarded "gnatmake" has been used in Ada build recipes - I have fixed some instances (to make sure that they use GNATMAKE_FOR_BUILD/HOST etc) .. but maybe missed some still ..... |
|
one other - possibly tangential - point. It seems that GH runners have several versions of Xcode installed - but default to the earliest (and broken for GCC) version. Apparently one can use sudo Xcode-select ... to pick a known good one. |
This build is to explore iains/gcc-14-branch#3; it's a minimally-modified GCC (OK, the MACOSX_DEPLOYMENT_TARGET update:) to be used for building the problematic 14.1.0. * common.sh (MACOSX_DEPLOYMENT_TARGET): 12.0. * gcc.sh (GCC_SRC): $SRC_PATH/gcc-13-branch.
|
For info - may be irrelevant - the host compiler (13.2.0) included a shim to link using ld-classic if found. This was largely because of the XC 15.0 issue, but also there was the exception handling issue fixed in GCC 13.3.0 (at least in Iains's version) and 14.1.0. I've just
Things are greatly improved, because I now get to this: I found this comment, so I'll have another go without |
Indeed my reaction was the same in this case too "what problem is that solving?" |
|
The note in their script says this was because of BZ 100340 -- which is RESOLVED FIXED. And removing it has resulted in a successful build!! Would you expect a compiler built against XC 15.n to run correctly under XC 15.{m < n}? There doesn’t seem to be a problem with XC 15.{m > n}. Is it worth trying to find which change actually fixed this problem? (it would be quite tedious) |
great!
This is not a reasonable scheme - the compiler is configured to use the facilities of 15.3 (which includes a working linker) - if you put it on a system with 15.0 installed, you are making it use a broken linker .. this will end badly :) (even apart form that) We (the volunteer devs) are an extremely limited resource. .. until we qualify a 15.4 CLT (which does not even appear to be released yet) - I think we have to say that the requirement is 15.3 (there are known bugs with earlier CLT versions). FWIW - I would love to have time to validate and include our own "binutils" so that these issues go away (or at least become ones we can solve) .. but that's yet another thing limited by resources Homebrew has similar policies - so I do not think your users should be too surprised - as previously noted even Xcode does not support this kind of mix and match - a toolchain is an incredibly complex entity with many moving parts .. it needs to be tested as a whole :) |
My previous build script was I just tried with 14.1.0 (r1) : complete success! One surprising thing: |
|
I think we're done here. Thanks for the help! |
|
IFF you use SDKROOT [environment] the compiler should honour that.
I think using
That is surprising .. and I expect it is also broken in use... I would like to repeat this, if possible - I fear that
What other environment (e.g. SDKROOT, MACOSX_DEPLOYMENT_TARGET)? |
I can't find a BZ about this? Current working setup: with
Having built as above,
So sorry, it was actually
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79885
That's expected, it's a plugin.
|
|
I have now seen this problem reported another time - but with no luck at pinning down what configure or environment was triggering it. What is your bootstrap gnat version? (i.e the one on $build, which I guess is the same as $host). |
Here during overload resolution we have two strictly viable ambiguous candidates #1 and #2, and two non-strictly viable candidates #3 and #4 which we hold on to ever since r14-6522. These latter candidates have an empty second arg conversion since the first arg conversion was deemed bad, and this trips up joust when called on #3 and #4 which assumes all arg conversions are there. We can fix this by making joust robust to empty arg conversions, but in this situation we shouldn't need to compare #3 and #4 at all given that we have a strictly viable candidate. To that end, this patch makes tourney shortcut considering non-strictly viable candidates upon encountering ambiguity between two strictly viable candidates (taking advantage of the fact that the candidates list is sorted according to viability via splice_viable). PR c++/115239 gcc/cp/ChangeLog: * call.cc (tourney): Don't consider a non-strictly viable candidate as the champ if there was ambiguity between two strictly viable candidates. gcc/testsuite/ChangeLog: * g++.dg/overload/error7.C: New test. Reviewed-by: Jason Merrill <[email protected]> (cherry picked from commit 7fed7e9bbc57d502e141e079a6be2706bdbd4560)
|
please could you try https://github.com/iains/gcc-14-branch/tree/gcc-14-2-darwin-pre-0 |
|
see also : https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116021 (which is about unpatched trunk) - so this is almost certainly not something to do with additional patches on the branch. |
A colleague is building
gcc-14.1-darwin-r0in a Github runner (macos-14 runs on an M1-based machine) and has problems with thegen_il-mainbuilt in stage 2.The stage1 compiler is aarch64-apple-darwin 13.2.0, which successfully builds and runs:
The stage2 compiler builds the same:
but when it’s run, this happens:
Could the Xcode/CLT version make a difference? The runner is running 14.4.1, and the default Xcode is 15.0.1.
The text was updated successfully, but these errors were encountered: