Xcode 15 + GCC = No simple build #1
Comments
|
We can actually build GCC/gfortran using XC15 - but it has somewhat ugly configuration and make environment values. What is your bootstrap compiler? |
|
@iains I guess clang-15? You can see some of my instructions here in my modulefile: https://github.com/mathomp4/m1modulefiles/blob/main/Core/gcc-gfortran/12.3.0.lua It's very basic and I don't even have a CC or CXX in the configure line. |
|
OK. are you able to ty an experiment? This is not enough if (1) you are using a previous version of GCC as the bootstrap compiler [i.e. the one that is used to build stage1 and $build system executables] (2) it is not capable of building Ada or D [because those cannot be built by clang] |
|
NOTE: Please DO NOT bake this change in; we are expecting Xcode to be fixed in due course, so that any actions in the short-term should be considered ephemeral work-arounds. |
|
@iains I'll give that a try. We are also trying the @fxcoudert method as well, if that works, that might be the "easier" path for our users. Our admins can make a "press this button" that installs it and for most users, that's good enough. 😄 |
|
Homebrew already ships GCC 13 with Xcode 15 on macOS Sonoma (both Intel and ARM). |
|
@fxcoudert Well, we have a couple issues.
|
Please file a Bugzilla - or, at least an issue here, especially if this is a regression (although we do need to be able to reproduce the problem)
Yeah - I suppose that the home-brew is re-writing the library paths to absolute values? unfortunately, that destroys the ability to relocate it .. NOTE: you are allowed to install things into /User/Shared/ that can be used by everyone on the machine |
One more question: do you happen to have the Intel version of your Ventura 12.2 somewhere? Our group is mostly on Arm macs now, but a couple are still on Intel waiting for their hardware refresh. (Of course, if the temp fix from @iains works, we can always build from scratch...though for Intel I guess we can go from "real" GCC tarball?) |
The "real" GCC tarball does not support the relocation yet (we are working on upstreaming those patches) - only matters if, say you want one team member to build it and share the result. |
Huh. Didn't know you could do that? Does that mean I don't really have to use your branch? I guess part of me figured "He knows M1, I'll keep using his code base!" 😄 |
You have to use the branch(es) for Arm64. |
|
for the record, we are actually making a determined effort to upstream for GCC14, but resources are limited (as always) |
|
Sigh. I guess we need to buckle down and figure out why GCC 13 hates our code if GCC 14 is coming along! :) |
|
Oh. I can confirm that using your new My colleague is trying the @fxcoudert bundle on his laptop and building the same stack. |
I'd be surprised if it works with Xcode 15, it was built against older Xcode. |
Interesting. Well, I haven't heard anything yet from him. Probably be tomorrow once the stack is built and tested. Meanwhile, I'm close to testing our model with the by-hand GCC... That said, I'm still rocking a built-by-xcode-14 |
|
Good news. Things seem to work with the build-by-hand GCC 12 using the @iains instructions (aka use Of course, bad news for me, for some reason our model dies if we aren't running with debugging options. Grah. Time for some tedious compiler flag exclusion experiments. |
OK that's a workaround then.
If you can, please try to produce some way in which we can reproduce your issue - and then we can try to fix whatever the underlying problem is. |
|
@iains More...oddities. A colleague of mine who used the @fxcoudert package for gfortran can get our model to run with Release flags. Now, in his case, he'd be using elseif (${proc_description} MATCHES "Apple M")
if (${CMAKE_HOST_SYSTEM_PROCESSOR} STREQUAL "arm64")
# Testing show GEOS fails with -march=native on M1 in native mode
set (GNU_TARGET_ARCH "armv8-a")
set (GNU_NATIVE_ARCH ${GNU_TARGET_ARCH})
elseif (${CMAKE_HOST_SYSTEM_PROCESSOR} STREQUAL "x86_64")
# Rosetta2 flags per tests by @climbfuji
set (GNU_TARGET_ARCH "westmere")
set (GNU_NATIVE_ARCH "native")
set (PREFER_AVX128 "-mprefer-avx128")
set (NO_FMA "-mno-fma")
endif ()which is what I first tested with. Now, I think I have an M2 mac and I want to say his was from an M1 refresh cycle. Do you know of any "M2 Mac optimization was wonky in GCC 12"? I'm going to try a run on an M1 I have access to see...but I can't imagine As noted above |
|
@mathomp4 without specific reproducers or errors, it is very hard to guess. “Fails” is unclear: do you mean compilation error, linking error, runtime error, or simply that the results are different/unexpected/invalid? A lot of factors come into play in large-scale numerical software. “Our model dies” could be invalid code exposed by a new optimisation, or a bug in the compiler, or many things |
|
@fxcoudert A bit annoying for me as well. This is what I get: Now, I mean, it is an executable as it ran for like a minute or two before this crash, so I'm not sure what 'executable file is not an executable' means. 🤷🏼 My usual plan of attack after this is "Let's run with debugging on" to get a good traceback, but, well, it runs with our debugging options! But, it is a segfault so memory got hosed somehow. I'm going to try and exactly duplicate what my colleague is using on my laptop. Same stack: compilers, MPI, libraries, etc. If I still crash, then that's a data point. Also, I just looked I can get a similar error (SIGSEGV or oddly SIGBUS) in some of our unit tests. So hopefully that can make tracking this down easier. (Though even this test requires our full stack: MPI, hdf5, netcdf, ESMF, GFE... so not quite at reproducer level yet.) |
|
New update. All is well on my M1 Max Mac Studio at work. This is...baffling. I mean, M1 and M2 aren't that different. The folks at archspec list And on my M1 and M2, Though |
|
Oh boy. This might be the same GCC 13 error we get with GEOS. I'm thinking I did something bad in my modulefiles and GCC 13 snuck in via "brew's I'm nuking everything and being careful. |
not the most helpful diagnostic ever written, it seems ...
|
I think that some work was done in the GCC-14 cycle to improve the --march=native for aarch64. However, there is no profile in the backend for either M1 or M2. Perhaps @fxcoudert will make a recommendation based on Homebrew's experiences - I would be happy to add the profiles (we collected the necessary data) but, unfortunately, we are already overloaded with getting the port prepared for upstreaming (so this is something for the future) ... AFAIR, the performance-related changes from M1->M2 are not that significant - the main addition is actually BTI which is more of a security thing + some 8bit vector/matrix ops - but I might misremember. In any event, I'd suggest not using edit : I think I'd stick with |
Oh. Huh. Okay. I can try doing that manually. It looks like doing it automatically isn't quite supported by CMake: |
|
Well, more updates. One, a very careful rebuild gives the same error. 😞 Two, using though I also still get: Now that traceback doesn't really help too much. It points to code that if it does fail should fail for all optimization types: 94 hconfig_key = ESMF_HConfigAsStringMapKey(hconfigIter,_RC)since ESMF was built the same no matter what. So, I guess the good news is that the @fxcoudert package seems to work for me as well, but surprising since that was built on XCode 14 and just being plopped into my Xcode 15 laptop. Meanwhile, a build of GCC 12.3 built by XCode 15 on the same system has an issue. Baffling... And I'm not even using fancy compiler options. Just ol |
|
One more update for myself. I decided to try I tried building with I think the answer is that Homebrew/homebrew-core#143368 with: # Work around a bug in Xcode 15's new linker (FB13038083)
if DevelopmentTools.clang_build_version >= 1500
toolchain_path = "/Library/Developer/CommandLineTools"
args << "--with-ld=#{toolchain_path}/usr/bin/ld-classic"
endonly applies to I'm going to try and remember how to do a self tap to see if I can insert that (and maybe other changes?) into a |
|
yes, this is all the same linker bug. The same workaround ( |
I'll try it out...once I remember how to do self taps in Brew. I do it so infrequently I forget how to do it everytime! 😄 |
|
Figured out the self tap and it seems to have built. I guess next up is a full GEOS stack to see if it works. If so, we can go back to using brew's build. I suppose I should make a PR to brew. I wonder, though, should I make it for all the GCC? @fxcoudert do you have advice? I can confidently say gcc@12 built, but I haven't done all the other versions... |
|
Yep. My self tap can build our full stack! I'll make a PR to brew. |
|
If possible, please consider making some reproducer for your GCC-13 problems and raise an issue here. Otherwise, should we consider this issue as resolved? |
|
Yes. I think so. Though I'm confused why the brew gcc@12 build works for me but not my "by hand" build of your 12.3 branch. Must be some magic sauce I'm missing in configure... |
We try very hard to avoid too much 'magic sauce' in configure lines (the intent is that the configure script should choose the correct settings for your environment). However, distributions do need to set paths etc. for their installations (and, I suspect, that the library path re-writing done by HB might be necessary for you to operate in step with an existing HB installation). So, in summary, either one needs to be operating "stand alone" (which in the case of GCC/gfortran means supplying the dependent libs - or building them along with the compiler) - or as part of a distribution (which means making any changes that the distribution does). So, if you're happy with the resolution - please close the issue (or let me know an I will) and @fxcoudert and I will very much look forward some day to a bug report for GCC13 :) |
As found in my group by @bena-nasa, xcode 15 does not build GCC anymore. This doesn't work by hand via the branch of @iains or via Homebrew.
We are trying to figure out the best/easiest way to effect a workaround. @iains says one way is back-installing XCode 14 but on our NASA maintained laptops this is...difficult.
Another path might be using the gfortran installer from @fxcoudert. I assume they built that with XCode 14 and since I can run gcc on my xcode 15 laptop with gcc from Homebrew (built by 14), that might work.
The text was updated successfully, but these errors were encountered: