-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gcc9 migration tracker #874
Comments
mathgl just got a new libN=8 that uses gcc11. Ancient mathgl6 is not used by anything. Can dist restrict or nuke outright. |
Many of these packages are deps on libraries using gccX (mostly via fftw). I've marked packages using fftw/fftw3 so that they can be updated at the same time if possible. |
No objection to dist-restricting mathgl6, or even nuking, given it has no reverse-depends. |
All my packages should be fine with gcc11. My Intel-Macbook died and I am on a M1-Macbook on macOS 12, which makes testing difficult. Ortep3 from Jack Fink should also be fine for a simple update. Should I submit a pull request or will someone of you guys act? |
openblas is in #875 |
If you set the Get Info for terminal to force it to use Rosetta then Fink will work as normal Intel based Terminal and all the processes it calls should be Intel code as well. I make a copy of the App and put it in my personal Applications folder and make that copy "rosetta" compatible so that I don't change the system version. |
I also added a fftw3 build in #876 . |
sth0: Interesting hint. Thanks for that. Still waiting for the regular support of macOS 12. Pull request initiated. |
lapack up through 380 FTBFS on gcc11 and only 350 is in use anymore. I dist-restricted 360/361/371/380 and they are all -shlibs only. They are probably fixable for gcc11, but is it worth it, especially for the unused stubs? Octave* are the only things using 350, and octave is using gcc5, so no hurry. |
What are the problems with 380? I could build it just switching to |
A bunch of:
Edit: it's not hard to fix these in many cases (and it's same/similar in older version), but just wondering if it's worth the effort. |
|
I tried to give
Looks vaguely familiar, but I'd defer to @mommsen or others to resolve this. Edit: seems the config tests are broken for the combination of |
Agreed; octave382 builds with the new lapack3 (and openblas) in #881 (though I also had fewer problems with 380...). |
@dhomeier I pushed updates for the root-related packages to gcc12. |
Would a separate GitHub issue for the underlying build problems be worth it, or are those just being tracked here as well? |
Also gcc11 does not build on OSX 13.6 / Xcode 15 / X86 (intel). There are 2 problems
R-base depends on gcc11-shlibs |
Sorry I may not have been clear, this is for Intel X86 and until R-base41 gets updated to use gcc12 (or later) I need gcc11 installed. Fortunately I installed it awhile ago but some newer fink or OS update broke the upgrade path for gcc11. I don't need the arm patches back ported. What ever caused the asan type libraries to go AWOL is architecture independent. |
Maybe #1033 was not documented very clearly – that PR is addressing both the builds for arm64 and x86_64, and hopefully also the Xcode 15 problems with the malformed patch. The
There is no need to backport anything at this point, and certainly nothing expected from anyone on the Fink team.
Yes, because support was removed in iains/gcc-darwin-arm64@e722a1f4 for all darwin > 21, and thus #1033 and #1080 are removing it from the Dist=13.0 builds on both architectures. |
Thanks to everyone who is working on this and trying to figure out what's possible and how to keep things reasonably portable and supportable. One detail I'd re-iterate is "Note 1", that it is not trivial to upgrade the gccXX version of an existing r-baseYY version. So for example r-base41 is fairly stuck at gcc11. The good news is that upstream R is now the 4.3 series, so rolling a new r-base43 is a chance to use the latest gccXX we have. |
I agree that upgrading the version of gcc for r-base is not trivial. I was just indicating why I had an interest in that older gcc11-shlibs and was trying to rebuild it. It may be that gcc11 broke in the update to Xcode 15 or the update to Ventura, I am not sure. I think it was the former since I updated the system from El Capitan to Ventura back in the spring and rebuilt everything successfully then. If the address sanitizer does not work in Xcode 15 and is removed from gcc12 and 13, (or 14) can it also be removed from gcc11 without horrible knock-on effects? Rolling a new R-base is good news, but that is a long road with all the cran-xx modules to test and update. |
That makes sense, and I agree there is no particular hurry for the existing r-base, as we have a working gcc 11.4 at this point.
To repeat, libsanitizer is already disabled for gcc11 in #1033 and removed from the package for Ventura (gcc11-13.0.info). |
Does it? Superficially appears like the same kind of undefined symbols for arch, but
(i.e. equivalent on Monterey to the darwin20.6.0 errors reported in fink-beginners) And there is no |
Even though it's for gcc8 and this is gcc9, MacPorts bug 64075 looks similar: https://trac.macports.org/ticket/64075 |
We're up to gcc11 now and gcc9 is reported to have build problems on OSX 11 (see fink-beginners Unable to update gcc9) and maybe even back to 10.15 (#844 comment on August 15)
The text was updated successfully, but these errors were encountered: