gcc-13.3-darwin-r0 tag build error on macOS14 ARM #20
Comments
|
:debug:main Starting logging for libgcc13 @13.2.0_4+stdlib_flag ^^^ This looks like it's related to 13.2 not 13.3? the 13.3 branch includes: |
|
No it's for 13.3 ignore that first part of the log |
|
apologies, that last log had some crude from an older 13.2 build at the start, but the bulk of it is indeed for 13.3. Here is a clean up version |
|
note, the way the macports builds work is they start from the stock upstream release tarballs, but then apply a patch file generated from the tag in your repo here, so the end result is what is built is exactly equivalent to your gcc-13.3-darwin-r0 tag |
|
final small log file clean up.... |
|
I should add gcc 13.2 builds just fine using the exact same procedure, applying a patch file that takes the build to your gcc-darwin-13.2-r0 tag. The issue above is new for the 13.3 release (and FWIW, I see exactly the same when attempting to build gcc 14.1 using your branch there). |
Do you know which tarball is being used in this case?
In principle, at least. I do build the release sources on as many systems as I have available - but, I suspect, that for 13.3 I only had x86_64 macOS14). |
This is surprising, let me see if I can repeat it - at the moment my test hardware is building/testing a rebase from the weekend, so it will not be immediate |
|
the tar ball is from the stock gcc release sites, e.g. but thats just the start, the p[atch file that is applied makes what is built identical to your tags here. |
one difference - I have not tried to build with Xcode 15.4 CLT .. are you able to test with 15.3? |
|
I'm not really that keen to downgrade TBH... |
I do not see an Xcode 15.4 CLT .. so perhaps there's no difference in those tools; which perhaps means there's a change in the SDK.. I know FX filed a Feedback about the @fxcoudert any ideas here? |
|
This patch is before the 13.3.0 tag on releases/gcc-13 - so I would have expected it to be in the release tarballs too. Perhaps there's yet another change in this in the Xcode 15.4 SDKs.. I not have those, since there's no XC15.4 CLT download. |
|
The source we build starts as the official 13.3.0 tarball which we then patch using a patch file generated from your repo tag which gets applied as so what we end up with is precisely whatever you have in your gcc-13-3-darwin-r0 tag. So if its in that, we are using it. |
|
for reference the patch file we apply to bring the stock release to your tagged version |
|
FWIW I just forcibly removed my CLT installation made sure my Xcode 15.4 was update to date, and then reinstalled the CLT with with that I tried building gcc 13.3 and get the same error. I am not sure what you mean by 'there's no XC15.4 CLT download' ? This procedure works fine for me. |
I just checked the release tarball - and FX's patch is in it ..
There is no separate Xcode 15.4 CLT download on Apple's Developer website; I do not, and will not, have multiple Xcode versions installed on all my test boxes it becomes unmanageable - CLT is hard enough. |
|
You don't have Xcode installed ? Only the CLT ? |
Then I guess, for me with Xcode 15.4 (and whatever CLT running |
|
So I ran a test build, going back to your previous tag, Here is the OK 13.2 build log for reference |
two things have changed; (1) the branch has got some improvements (2) it seems that the SDK has changed, in some way. Almost certainly updates that relate to the improved coverage of floating point types have triggered this; but it is also the case that the branch does build fine with earlier Apple SDKs using the |
Here is the from the SDK I am using (15.4) . can you compare it to what you have with 15.3 to see what has changed ? |
|
b.t.w., and please bare with me here as I know next to nothing about how GCC's 'fixincludes' work, but the error I see is whereas in the patch you mention above it mentions errors like Could it be for some reason in the builds I have the |
|
b.t.w. The CLT I have installed is still 15.3 So likely the same as what you have anyway. |
In this case, what probably matters is the SDK in use. |
|
for the record I just confirmed a build of GCC-13.3-darwin-r1 on macOS14.5: (I'm using GCC to bootstrap, because of building Ada and D too). |
Now I am very confused - that file is the same as the one in the SDK I am using - and which [as per the comment above] built and tested fine from my branch. I'm now doing a build with clang as the bootstrap compiler (so no Ada or D). |
|
Could it also be related to the configure options we use, which are perhaps not the usual ones (you can find an example of what we use in the logs) ? |
Normally the fix for that header is in GCC 13.3 upstream (https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=87e6cc0103369f8891c3c3a516f4d93187c2c12b). Can you confirm what is the value of |
@cjones051073 We probably need to verify it works the same when bootstrap it done with gcc instead of clang. The breakage can be clang-specific. |
|
Okay, bootstrapping with gcc on 14.5 did not go far, failing right at configure: Notice it passes |
|
gcc 15 when building from MacPorts set-up also passes MacPorts include path across the build, so yeah, I guess this is wrong and we should remove it: (Just some random line from the log to illustrate the point.) |
We've fixed this, and I've back ported to a local 10.5 + lots of Darwin extras .. I plan to publish that but (as usual) subject to time constraints - in short, the problem above is different. |
|
@barracuda156 boot strapping from gcc is not something we do on our primary platforms, its only an issue for people like yourself trying to keep ancient OSes going, so whilst you are welcome to test things there its not a concern in general. I also do not expect @iains to expend any energy on why it works for you on OSX10.6... In any case these sorts of issues we should discuss elsewhere, on macports channels. From what I can see dropping the use of the option seems OK so far (and likely its anyway no longer doing what it did when we started using it a good few years back) so I am likely to push an update to 13.3 soon and we can then follow up any residual issues elsewhere. |
So, indeed, setting this somewhere unexpected is going to mess up the search process - what is somewhat amazing is that it has worked before. Sadly, configure options get added for obscure reasons and then get brought forward to times long after they are needed or correct ... it would not do any harm to audit what remains for correctness. |
|
The way I read the description from the configure help you post above this option controls where the header files are written, not where a set of system headers are read from. So I do think what this option does in practise does not really match the help there, I must say. |
|
We set a number of options to control where things are written, see Unless I am mistaken the lib, info and man equivalents work the way we understood, they control where output is written no ? So if so I think the lack of consistency with what the includedir option does is a bit confusing. |
I think, actually, they all work in similar ways - that is control the expected layout of the toolchain in the directory structure.
(BTW, just for info) The defaulting of linkers to search /usr/lib (or /lib on Linux) can cause its own set of problems with things being found that the user did not really intend. One day, perhaps this will be made explicit and then we would find the same issue with missing /usr/lib. |
@cjones051073 Well, in general bootstrapping with gcc is a concern, of course, in may not be a concern in MacPorts.
We have very few issues which are specific to 10.6, and @iains is well aware of those. With gcc it is perhaps 1 issue.
I kinda begin wondering how was it working fine so far – it should have broken things. |
|
So removing the use of instead of where we want them which is Luckily, we can still control where the C++ headers end up with @iains I can only agree that this dual use of the option |
|
@cjones051073 Please ping me when to test your branch. |
This is because you want them installed per gcc version?
I suppose that there's an expectation in some cases that the toolchain is part of the distribution - and therefore integrated into it; this is not the case with GCC on macOS (since 10.7 anyway). Perhaps there is a way - but I have never used or tested it - so you'd need to experiment: IFF (and this I do not know) We could always make some darwin-specific configuration changes - but the general layout is quite deep in the libtool stuff, so we'd be carrying the patch forever (I'd expect). |
Correct. We offer multiple gcc versions in MacPorts and require them to be installable side by side, which implies each has to stick to its own versioned prefix. |
Yeah, I was just looking at that oldincludedir flag and was going to ask what its intended use case was. We could try using it, but what still confuses me a bit is the configuration is already being told the SDK to use via |
Actually, I did not (yet) read the install page to see if there's a larger description - will do that later.
The "sysroot" is the base of a tree which represents what's installed on a system. So all the used paths are relative to that - and for systems (like Linux and Darwin before 10.11) that can have their headers and libraries installed in So it makes no statement about how the installation is laid out - only tells the compiler where to start looking. |
Also introduces some small tweaks to the configuration to address issues in iains/gcc-13-branch#20 most specifcally, removing the use of the --includedir configuration parameter, as this does more than it was understood to do and in fact also controls *where* gcc expects to find C headers, not just where it writes its output too, which was the understanding.
|
@cjones051073 @iains It is still broken on Sonoma. Same error as before. Also |
|
Macports buildbots have no problems, so whatever this is its unique to your setup. |
Well, perhaps something in MacPorts prefix break it, but the point is that nothing changed in this regard, the flag is passed as before. Here for gcc13: |
|
Please compare yourself to the logs from the buildbot |
The I can see that the build succeeds, but that only means that it is unpredictable, and something installed breaks it. (Perhaps only on Sonoma or only on arm64, since I have no issues on 10.6.) I will deactivate all ports and try building from scratch on 14.5. |
|
@iains @cjones051073 Well, it still fails. Perhaps buildbots use an old Xcode? Or different tarballs give different results? I tried deactivating everything and building I have also removed all custom ports (even though nothing relevant was there anyway). |
|
@cjones051073 So nothing conflicting in MacPorts prefix can cause the breakage, that is ruled out. |
|
Please stop posting about this here, as I doubt its related to this issue, and we should not spam @iains on something that might be a macports packaging issue. Open a ticket about it in the macports trac system and we can discuss there. It if turns out we think its a gcc issue you can open a new issue for that in due course. |
|
Okay, please ignore, on a fifth attempt it worked. I have no idea what is the difference ( |
For the record, there is a facility For parallel instals of different GCC versions, we should expect that to 'just work' - i.e. that files that are specific to one version of the compiler are local to that compiler's installation (e.g. fixed includes, or the libgcc runtimes). If that is not happening then we need to file bug(s) to fix it. NOTE; this is also a common practice on Linux (multiple GCC versions installed) so if it was failing disastrously we'd expect to have heard :) It's possible that you are defeating some/all of the provisions by being specific about paths - the configure philosophy is to assume that the person configuring knows the exact consequences of what they are changing .. otherwise its goal is to pick the most suitable set of options for the platform. Probably, since we have had some active maintenance now for several years and have moved quite a bit forward in supporting some of the macOS-specific requirements, it might be worth starting from "what do we want to achieve"? and making sure we only specify the minimum to do that. |
MacPorts uses a single |
Which is fine, providing the user cannot down-grade it from the latest .. (barring some issues we have at the moment with macOS15 etc having dropped some symbols.. but let's not worry about that here, yet). edit: NOTE I think that this would only apply to the shared library since static libraries and other CRTs are found local to the compiler - and that should be the case, since the set of CRTs can change. |
|
I had a quick run through the long discussion here - but was unable to determine if it's "fixed" or we figured out why there was an issue - is anyone still having problems? |
Using latest gcc gcc-13.3-darwin-r0 tag
Full configure and build log attached
main.log.gz
The text was updated successfully, but these errors were encountered: