Linking OpenBLAS wrong on OSX

[vbraun]

On OSX, various binaries link libopenblas_$ARCH-$VERSION.dylib instead of the symlink libopenblas.dylib. This obviously breaks Sage whenever we upgrade the openblas version...

osx:build buildbot-sage$ otool -L local/lib64/libffpack.dylib
local/lib64/libffpack.dylib:
	/Users/buildbot-sage/slave/sage_git/build/local/lib/libffpack.1.dylib (compatibility version 2.0.0, current version 2.0.0)
	/Users/buildbot-sage/slave/sage_git/build/local/lib/libgivaro.9.dylib (compatibility version 10.0.0, current version 10.2.0)
	/Users/buildbot-sage/slave/sage_git/build/local/lib/libgmp.23.dylib (compatibility version 24.0.0, current version 24.3.0)
	/Users/buildbot-sage/slave/sage_git/build/local/lib/libgmpxx.8.dylib (compatibility version 13.0.0, current version 13.3.0)
	/Users/buildbot-sage/slave/sage_git/build/local/lib/libfflas.1.dylib (compatibility version 2.0.0, current version 2.0.0)
	/Users/buildbot-sage/slave/sage_git/build/local/lib/libopenblas_penrynp-r0.3.6.dylib (compatibility version 0.0.0, current version 0.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.4)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.250.1)

On Linux, everything is linked against libopenblas.so as it should.

CC: @jhpalmieri @embray @mkoeppe

Component: packages: standard

Issue created by migration from https://trac.sagemath.org/ticket/28008

[dimpase]

comment:2

is it because these binaries ignore pkg-config data, or is it faulty pkg-config data?

[jhpalmieri]

comment:3

$ sage --sh
$ pkg-config --libs cblas
-L/Users/jpalmier/Desktop/Sage/git/sage/local/lib -lopenblas
$ pkg-config --cflags cblas

The fflas_ffpack spkg-install script calls these pkg-config commands at the start.

[jhpalmieri]

comment:4

Is this a blocker? It will prevent upgrading Sage from 8.7 to 8.8 on OS X.

[dimpase]

comment:5

What if we copy dynlibs on MacOS rather than create symlinks? It seems that this is what Apple is actually doing:
e.g. here we can see that libz.1.dylib is actually the real library, and the remaining libz.*dylib are just symbolic links.

lrwxr-xr-x  1 root  wheel      12 11 Jan  2018 /usr/lib/libz.1.1.3.dylib -> libz.1.dylib
lrwxr-xr-x  1 root  wheel      12 11 Jan  2018 /usr/lib/libz.1.2.11.dylib -> libz.1.dylib
lrwxr-xr-x  1 root  wheel      12 11 Jan  2018 /usr/lib/libz.1.2.5.dylib -> libz.1.dylib
lrwxr-xr-x  1 root  wheel      12 11 Jan  2018 /usr/lib/libz.1.2.8.dylib -> libz.1.dylib
-rwxr-xr-x  1 root  wheel  186432  1 Dec  2017 /usr/lib/libz.1.dylib
lrwxr-xr-x  1 root  wheel      12 11 Jan  2018 /usr/lib/libz.dylib -> libz.1.dylib

And linking to libz leads to linking to /usr/lib/libz.1.dylib

So we can do the same (on MacOS only, arrgh...): always install openblas.dylib under a short name, and the long names would just be symlinks.

[dimpase]

comment:6

Replying to @jhpalmieri:

Is this a blocker? It will prevent upgrading Sage from 8.7 to 8.8 on OS X.

Why is this openblas-specific?
I imagine the same would be a problem with any Sage library version bump on OSX...

[jhpalmieri]

comment:7

Replying to @dimpase:

Replying to @jhpalmieri:

Is this a blocker? It will prevent upgrading Sage from 8.7 to 8.8 on OS X.

Why is this openblas-specific?
I imagine the same would be a problem with any Sage library version bump on OSX...

Good question. I upgrade Sage frequently on several different OS X machines, and this is the first time I remember having this problem.

[vbraun]

comment:8

I can only guess why you haven't seen this before, but we don't upgrade openblas that often. Plus we used to not delete old files so you might have not realized that you were still using the old version.

Having linked the wrong library there is little we can do to fix it, you really do need to do a make clean. Its not something that dependency tracking in the buildsystem can or should do for you. We probably should have a flag somewhere that does the make clean for you if you cross a certain version, but we don't. So realistically I don't think we can fix this right now.

[dimpase]

comment:9

Another guess might be that the dependency on $(BLAS) is not 100% properly processed, and the corresponding generated makefile rules do not trigger the needed rebuilds.

Or perhaps the need to rebuild is not working for some other reason.

Perhaps Erik may say something about it.

[embray]

comment:10

Moving tickets from the Sage 8.8 milestone that have been actively worked on in the last six months to the next release milestone (optimistically).

[embray]

comment:11

I still don't know very well how Mach binaries or the MacOS linker work, but as this article suggests it does need to have the full, real path to linked dylibs in the binary, and so it may be necessary to muck around in some ways with install_name_tool, which I have done before.

One day I need to bite the bullet and study more about how MacOS works in this regard so that I can be more useful.

[embray]

comment:12

Ticket retargeted after milestone closed

[mkoeppe]

comment:14

Moving tickets to milestone sage-9.2 based on a review of last modification date, branch status, and severity.

[mkoeppe]

comment:16

Sage development has entered the release candidate phase for 9.3. Setting a new milestone for this ticket based on a cursory review.

[mkoeppe]

comment:17

Setting a new milestone for this ticket based on a cursory review.

[mkoeppe]

comment:18

Stalled in needs_review or needs_info; likely won't make it into Sage 9.5.