Opened 6 months ago

Last modified 4 months ago

#28008 needs_info defect

Linking OpenBLAS wrong on OSX

Reported by: vbraun Owned by:
Priority: major Milestone: sage-8.9
Component: packages: standard Keywords:
Cc: jhpalmieri, embray Merged in:
Authors: Reviewers:
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Description

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.

Change History (11)

comment:1 Changed 6 months ago by vbraun

  • Cc jhpalmieri added

comment:2 Changed 6 months ago by dimpase

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

comment:3 Changed 6 months ago by jhpalmieri

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

Version 0, edited 6 months ago by jhpalmieri (next)

comment:4 follow-up: Changed 6 months ago by jhpalmieri

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

comment:5 Changed 6 months ago by dimpase

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.

Last edited 6 months ago by dimpase (previous) (diff)

comment:6 in reply to: ↑ 4 ; follow-up: Changed 6 months ago by 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...

comment:7 in reply to: ↑ 6 Changed 6 months ago by jhpalmieri

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.

comment:8 Changed 6 months ago by vbraun

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.

comment:9 Changed 6 months ago by dimpase

  • Cc embray added
  • Status changed from new to needs_info

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.

comment:10 Changed 5 months ago by embray

  • Milestone changed from sage-8.8 to sage-8.9

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).

comment:11 Changed 4 months ago by embray

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.

Note: See TracTickets for help on using tickets.