[CompilerSupportLibraries_jll] Upgrade to libraries from GCC 12

[giordano]

Usual memo to self:

• change the version number in stdlib/CompilerSupportLibraries_jll/Project.toml
• update CSL_NEXT_GLIBCXX_VERSION in deps/csl.mk
• update hashes with make -f contrib/refresh_checksums.mk -j csl
• since the soversion of libgcc_s for x86_64-darwin changed, update all references to the version number wherever it's mentioned (I hope I got them all)

Note 1: this lets us effectively test in CI #44829 is fixed
Note 2: I marked this to be backported to julia v1.6, but this will first require backporting #45249, which seems to be stalling.

[giordano]

I have no idea what's wrong with Windows (lots of undefined references to llvm functions at linking time for libjulia-internal.dll).

[giordano]

Alright, we have a problem. In https://github.com/JuliaPackaging/Yggdrasil/blob/7639eb0a7a1ec9d21cb8701925b4ec4f0257423e/C/CompilerSupportLibraries/build_tarballs.jl we always use the latest version of libgomp and libstdc++, independently from the version of libgfortran (this is for example important to solve the issue with undefined references to GLIBCXX symbols). However, GCC 12 changed the ABI of libgcc_s for x86_64-darwin, which is now called libgcc_s.1.1.dylib instead of libgcc_s.1.dylib. But this means in the libgfortran{3,4} versions of CSL we have libstdc++ which requires libgcc_s.1.1.dylib (because this comes from the latest version) but all the other libraries (e.g. libgfortran) which require libgcc_s.1.dylib, so they can't really coexist. I'm not sure how to address this issue. @staticfloat ideas? A datapoint: as far as I can tell, the macOS version of libtsdc++ doesn't have the infamous GLIBCXX symbols, so maybe we can not use the latest version of libstdc++ on macOS?

[staticfloat]

but all the other libraries (e.g. libgfortran) which require libgcc_s.1.dylib, so they can't really coexist.

Do we know that they actually can't co-exist? 😈

[giordano]

Julia now builds on x86_64-darwin. Still linking errors on Windows for libjulia-internal.dll, no clue why. Why libgcc would even affect resolution of llvm symbols?

[fxcoudert]

Not sure what the windows error is due to, but the macOS part looks good to me.

[giordano]

Linking on windows now works (without having changed anything here), but Julia fails to bootstrap. What's wrong always with Windows?

[giordano]

Right, this requires #45649, otherwise the Float16 tests are failing.

Going back to Windows, the error now is:

ERROR: `ccall` requires the compiler
make[1]: *** [sysimage.mk:58: /cygdrive/c/buildbot/worker/package_win64/build/usr/lib/julia/corecompiler.ji] Error 1

which looks similar to issues mentioned in #45857 and #45641 (comment). If that's the case, it means Julia is picking the wrong libstdc++? I can't debug much myself anything related to Windows, so I'd need help from someone with access to a Windows box 🙂

[JeffBezanson]

What's the status of this? Still seems to have build problems. Is this release-blocking?

[giordano]

I can't do much about Windows, I don't have a Windows box (and zero experience with Windows anyway). I'm surprised by the macOS failure, also because it was working before the last rebase, but haven't had the time to look into that. It's probably not a release blocker strictly speaking, but it'd be nice to get this in: just see at the people having problems with the old libstdc++ shipped by Julia in JuliaGL/GLFW.jl#198.

[IanButterworth]

Just doing a merge-up and rerun, given Mosé is on vacation for 3 weeks. Just in case it all goes green

[IanButterworth]

MacOS now built and I believe the test fail is a known FileWatching issue, but the windows issues remain and it's not obvious to me why

[inkydragon]

missing _ZSt14__once_functor in libstdc++-6.dll

---

Update: What is the full version number of our gcc12?

Maybe we need this patch?

libstdc++: Check for TLS support on mingw cross-compilers
Native mingw builds enable TLS, but crosses don't because we don't use
GCC_CHECK_TLS in the cross-compiler config.

gcc-mirror/gcc@cc1e288

[vtjnash]

This commit message is a bit messy, and seems to claim to add debug checks and revert commits that aren't part of Julia. Please be conscientious when merging so that they are easily readable to others.

[vtjnash]

I think this broke compilation with gcc <= 10 on Windows, due to something about the lib/*.a files being incompatible or something. Building in wine after this commit results in:

    JULIA julia-win32/usr/lib/julia/corecompiler.ji
ERROR: Unable to load dependent library Z:\data\vtjnash\julia\julia-win32\usr\bin\../bin/libjulia-internal.dll
Message:Bad EXE format for %1. 
make[1]: *** [/data/vtjnash/julia/sysimage.mk:61: /data/vtjnash/julia/julia-win32/usr/lib/julia/corecompiler.ji] Error 1
make: *** [/data/vtjnash/julia/Makefile:84: julia-sysimg-ji] Error 2

If we then do

$ /bin/tar -xmvf deps/srccache/CompilerSupportLibraries.v0.5.4+0.i686-w64-mingw32-libgfortran5.tar.gz -C julia-win32/usr lib

to get the lib files from the previous version back and then re-link julia (e.g. rm usr/bin/libjulia-internal.dll && make), it works again.

Perhaps we now need to avoid installing these lib/*.a files, and only get the updated/upgraded dll files?

[staticfloat]

We have been thinking about eliminating .a files from JLLs for a while now. They are often more trouble than they're worth.

[giordano]

@vchuravy needed them for #47184. Static libraries for Windows were introduced in #47332, not here.