search

fink / fink-distributions

Package descriptions and patches for Fink
24 stars 38 forks source link

gcc9 migration tracker #874

Open dmacks opened 2 years ago

dmacks commented 2 years ago

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)

nieder commented 2 years ago

mathgl just got a new libN=8 that uses gcc11. Ancient mathgl6 is not used by anything. Can dist restrict or nuke outright.

nieder commented 2 years ago

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.

dmacks commented 2 years ago

mathgl just got a new libN=8 that uses gcc11. Ancient mathgl6 is not used by anything. Can dist restrict or nuke outright.

No objection to dist-restricting mathgl6, or even nuking, given it has no reverse-depends.

kamischi commented 2 years ago

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?

dhomeier commented 2 years ago

openblas is in #875

sth0 commented 2 years ago

My Intel-Macbook died and I am on a M1-Macbook on macOS 12, which makes testing difficult

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.

dhomeier commented 2 years ago

I also added a fftw3 build in #876 .

kamischi commented 2 years ago

sth0: Interesting hint. Thanks for that. Still waiting for the regular support of macOS 12. Pull request initiated.

dmacks commented 2 years ago

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.

dhomeier commented 2 years ago

lapack up through 380 FTBFS on gcc11 and only 350 is in use anymore.

What are the problems with 380? I could build it just switching to Type: gcc (11) (10.14, Xcode 11.3.1.0.1.1576735732).

dmacks commented 2 years ago

lapack up through 380 FTBFS on gcc11 and only 350 is in use anymore.

What are the problems with 380? I could build it just switching to Type: gcc (11) (10.14, Xcode 11.3.1.0.1.1576735732).

A bunch of:

gfortran-fsf-11 -O2 -fimplicit-none -funroll-loops -fPIC -m64 -c -o sdrvls.o sdrvls.f
sdrvls.f:468:47:

  361 |      $                                    B, LDB, WQ, -1, INFO )
      |                                                  2
......
  468 |      $                                    LDB, WORK, LWORK, INFO )
      |                                               1
Error: Rank mismatch between actual argument at (1) and actual argument at (2) (scalar and rank-1)

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.

nieder commented 2 years ago

-fallow-argument-mismatch generally takes care of that type of failure with gcc10+ https://salsa.debian.org/debian/xfoil/-/blob/master/debian/patches/fix-compilation-with-gcc-10.diff

dhomeier commented 2 years ago

I tried to give root5-cernlib a push to 10.14.5 since I only have a Mojave system to test on now, but after getting through some issue with the System OpenGL and Ruby libs, failed early in the build with

clang++ -O2 -m64 -pipe -Wshadow -W -Wall -Woverloaded-virtual -fsigned-char -fno-common -Iinclude -DR__HAVE_CONFIG   -stdlib=libstdc++   -pthread -DINCLUDEDIR=\"/usr/include\" -DOBJSUFFIX=\".o\" -o build/rmkdepend/mainroot.o -c /private/var/tmp/fink.build/root5-cernlib-5.34.38-3/root/build/rmkdepend/mainroot.cxx
warning: include path for stdlibc++ headers not found; pass '-stdlib=libc++' on the command line to use the libc++ standard library instead
      [-Wstdlibcxx-not-found]
/private/var/tmp/fink.build/root5-cernlib-5.34.38-3/root/build/rmkdepend/mainroot.cxx:28:10: fatal error: 'string' file not found
#include <string>

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 libcxx and cxx11, also the Xcode SDK /usr/include is not found, which both can be forced to do it right, but still running into failures on cmath.h after that.

dhomeier commented 2 years ago

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.

Agreed; octave382 builds with the new lapack3 (and openblas) in #881 (though I also had fewer problems with 380...).

dmacks commented 2 years ago

hdf (old version, discussed in #887) updated (b75bfb39dd18cbeb34732ef44e52a78caefb2fd1) and cascaded BuildDepends/rev-up because it's a static-only lib (261bc6696ae6742999ecb1ff52f9db18e9ba05b4)

dmacks commented 1 year ago

@dhomeier I pushed updates for the root-related packages to gcc12.

cooljeanius commented 12 months ago

gcc9 is reported to have build problems on OSX 11 (see fink-beginners Unable to update gcc9)

Would a separate GitHub issue for the underlying build problems be worth it, or are those just being tracked here as well? (edit: FWIW, it looks like the underlying build problem here for gcc9 is just the usual Big Sur libtool linking bug that's been reported in #859 and various other bugs...)

sth0 commented 12 months ago

Also gcc11 does not build on OSX 13.6 / Xcode 15 / X86 (intel). There are 2 problems

  1. the fink version of "patch" must be installed
  2. If you add patch to the build depends then it fails on the asan libraries.

R-base depends on gcc11-shlibs

dhomeier commented 12 months ago

So is this still an issue with #1033?

Should also note that there is no build for gcc 9 or 10 at all on arm64, and I would not expect the arm64 patches to continue being backported to gcc11 indefinitely. So the better path might be to migrate to gcc12 or 13 (tested in #1080) already.

sth0 commented 12 months ago

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.

dhomeier commented 12 months ago

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 gcc11-arm.patch seems to have caused some confusion, but actually it contains just changes enabling the build on arm64 that should (and for everything I have tested so far, do) still build just as well on x86_64, and hopefully will be merged upstream into gcc 13 or 14 main at some point. There is no specific patch for x86_64 (which should basically build without any patches).

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.

There is no need to backport anything at this point, and certainly nothing expected from anyone on the Fink team. But arm64 development in iains/gcc-darwin-arm64 is already based on gcc 14, just wanted to point out that I would not hold my breath that patch series will continue to be available for gcc 11.5, or 11.6 or some later version – in any case this is already lower priority now. So at that point we may face the choice to not update gcc11 any further, or only provide an update for x86_64, but not arm64. So for anything that is now due to be migrated from gcc9 or earlier, moving right away to gcc12 or gcc13 should be safer. But it is certainly not urgent for those packages that already depend on gcc11.

What ever caused the asan type libraries to go AWOL is architecture independent.

Yes, because support was removed in https://github.com/iains/gcc-darwin-arm64/commit/e722a1f4 for all darwin > 21, and thus #1033 and #1080 are removing it from the Dist=13.0 builds on both architectures.

dmacks commented 12 months ago

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.

sth0 commented 12 months ago

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.

dhomeier commented 12 months ago

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.

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?

To repeat, libsanitizer is already disabled for gcc11 in #1033 and removed from the package for Ventura (gcc11-13.0.info). If it should nonetheless not build with Xcode 15, please comment in the PR.

cooljeanius commented 12 months ago

Could we just get a simple fix for the Big Sur libtool linking bug for gcc9 before worrying about doing any sort of major migration? See e80c5d6 by @dmacks for a recent example of a patch fixing the bug in question.

dhomeier commented 12 months ago

Would a separate GitHub issue for the underlying build problems be worth it, or are those just being tracked here as well? (edit: FWIW, it looks like the underlying build problem here for gcc9 is just the usual Big Sur libtool linking bug that's been reported in #859 and various other bugs...)

Does it? Superficially appears like the same kind of undefined symbols for arch, but 

g++ -std=gnu++98   -g  -DIN_GCC    -fno-strict-aliasing -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H  -DGENERATOR_FILE -fno-PIE -Wl,-headerpad_max_install_names -no-pie -o build/gencondmd \
        build/gencondmd.o ../build-x86_64-apple-darwin21.6.0/libiberty/libiberty.a
clang: warning: argument unused during compilation: '-no-pie' [-Wunused-command-line-argument]
ld: warning: -no_pie is deprecated when targeting new OS versions
Undefined symbols for architecture x86_64:
  "_cfun", referenced from:
      ___cxx_global_var_init.99 in gencondmd.o
  "_epilogue_completed", referenced from:
      ___cxx_global_var_init.99 in gencondmd.o
  "_flag_cf_protection", referenced from:
      ___cxx_global_var_init.99 in gencondmd.o
  "_flag_finite_math_only", referenced from:
      ___cxx_global_var_init.99 in gencondmd.o
  "_flag_fp_int_builtin_inexact", referenced from:
      ___cxx_global_var_init.99 in gencondmd.o
  "_flag_peephole2", referenced from:
      ___cxx_global_var_init.99 in gencondmd.o
  "_flag_pic", referenced from:
      ___cxx_global_var_init.99 in gencondmd.o
  "_flag_rounding_math", referenced from:
      ___cxx_global_var_init.99 in gencondmd.o
  "_flag_trapping_math", referenced from:
      ___cxx_global_var_init.99 in gencondmd.o
  "_flag_unsafe_math_optimizations", referenced from:
      ___cxx_global_var_init.99 in gencondmd.o
  "_insn", referenced from:
      ___cxx_global_var_init.99 in gencondmd.o
  "_ix86_arch_features", referenced from:
      ___cxx_global_var_init.99 in gencondmd.o
  "_ix86_cmodel", referenced from:
      ___cxx_global_var_init.99 in gencondmd.o
  "_ix86_fpmath", referenced from:
      ___cxx_global_var_init.99 in gencondmd.o

(i.e. equivalent on Monterey to the darwin20.6.0 errors reported in fink-beginners) look a bit more fundamental that the Tcl linker failures for graphviz. In any case I have not seen any real news on macOS 11/12 support since https://github.com/fink/fink-distributions/pull/844#issuecomment-1002981610

And there is no *-apple-darwin[91]* in gcc9 configure; it's already *-apple-darwin[912]* everywhere, so just that part of the patch will probably not do.

cooljeanius commented 1 week ago

Even though it's for gcc8 and this is gcc9, MacPorts bug 64075 looks similar: https://trac.macports.org/ticket/64075