BinaryBuilder dependencies bump #34242
Conversation
staticfloat
force-pushed
the
sf/bb_bump
branch
from
89ea554 to
bbe8fbd
Compare
staticfloat
force-pushed
the
sf/bb_bump
branch
from
bbe8fbd to
eb8b8cf
Compare
|
And because I often screw this up, here is a build with no BB dependencies: https://build.julialang.org/#/builders/147/builds/8 |
|
Hmmm, win32 has a signal 11 (is that still segfault on windows?) when just trying to run Julia to print out version info. That's not good. |
|
I'm seeing even the shell segfault: https://build.julialang.org/#/builders/31/builds/8176/steps/3/logs/stdio. Did the BinaryBuilder download overwrite something? |
|
This is great but it's not clear to me whether it's backportable --- maybe we should merge #34225 for now? Or perhaps only on release-1.4? |
Unsure; I looked into the logs and it seems that a lot of the builders have been segfaulting. I've rebooted them to see if that fixes it, if not I'll inspect the bots a bit, and if I can't figure it out quickly, I'll just rebuild them. |
|
To play it safe, I think I should build a special 0.3.5 release of OpenBLAS with Keno's patches, integrate those into #34225, land those on 1.3/1.4, and this can go into |
staticfloat
force-pushed
the
sf/bb_bump
branch
from
598ba89 to
9286b49
Compare
It's also no longer libgfortran-dependent, so flip that flag and reduce the number of separate files by 2/3rds.
This will require us to change our LLVM and OpenBLAS binaries, as they are the only libgfortran-specific libraries that we ship with base Julia.
After much debugging, it turns out that OpenBlas is sometimes hanging on exit due to bad assumptions in its thread management. The upstream discussion is at OpenMathLib/OpenBLAS#2350, but this should fix our frequent win32 CI failures in the meantime.
staticfloat
force-pushed
the
sf/bb_bump
branch
from
9286b49 to
2b4b3d5
Compare
This PR contains a number of BinaryBuilder-related improvements:
-gccXtags to the much more explicit-libgfortranXtags that BB has been spitting out for over half a year now. This necessitates changingOpenlibm,OpenBLASandLLVMat the least, as all of these dependencies were marked as having a dependency on GCC version/libgfortran version.OpenLibmto a new release that happily removes the incorrect dependence onlibgfortran.OpenBLAStov0.3.7, including the new threading patches from @Keno.LLVMchecksums to honor the upgraded naming convention.