conda-forge/arpack-feedstock

linking issues in Mac build

Closed this issue · 10 comments

There are some linking issues with the Mac build:

$ conda create -n tmp arpack
[...]

$ cd $ANACONDA_PREFIX/envs/tmp/lib
cmake					libgfortran.2.dylib			libopenblas_nehalemp-r0.2.19.a
libarpack.a				libopenblas.a				libopenblas_nehalemp-r0.2.19.dylib
libarpack.dylib				libopenblas.dylib

$ otool -L libarpack.dylib
libarpack.dylib:
	@rpath/libarpack.dylib (compatibility version 0.0.0, current version 0.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)
	@rpath/libopenblasp-r0.2.19.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libgfortran.3.dylib (compatibility version 4.0.0, current version 4.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
	/Users/ray/mc-x64-3.5/conda-bld/gcc-4.8_1477649012852/_b_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
	@rpath/libquadmath.0.dylib (compatibility version 1.0.0, current version 1.0.0)

Two linking problems here:

  • the libgcc_s.1.dylib link that doesn't have an @rpath in it but does the full placeholder path for some reason
  • the link to @rpath/libopenblasp-r0.2.19.dylib, which doesn't exist

(The Linux build seems fine.)

I think that (maybe) the first problem could be solved by adding libgcc as a runtime dependency on OSX, and the second one might be solved just by a rebuild and dependency update against the new openblas?

Probably just needs a build number bump. The @rpath issue is due to a bad gcc/libgcc that was briefly available. This package shouldn't need to rely on libgcc as libgfortran already satisfies the library dependencies (including libgcc_s).

Could you retry in a few minutes when the 3.5.0 update is published ?

Actually, no, it's still linking to @rpath/libopenblasp-r0.2.19.dylib....

libopenblasp-r0.2.19.dylib is part of openblas from conda-forge though, which openblas package have you got ?

@jschueller Not in the version I'm getting on Mac. There's lib/libopenblas_nehalemp-r0.2.19.dylib instead:

$ cat $ANACONDA/pkgs/openblas-0.2.19-1/info/files
include/cblas.h
include/f77blas.h
include/lapacke.h
include/lapacke_config.h
include/lapacke_mangling.h
include/lapacke_utils.h
include/openblas_config.h
lib/cmake/openblas/OpenBLASConfig.cmake
lib/cmake/openblas/OpenBLASConfigVersion.cmake
lib/libopenblas.a
lib/libopenblas.dylib
lib/libopenblas_nehalemp-r0.2.19.a
lib/libopenblas_nehalemp-r0.2.19.dylib

@jschueller Oh, it looks like this is the package from the default repos:

https://repo.continuum.io/pkgs/free/osx-64/openblas-0.2.19-1.tar.bz2

I have conda-forge at a lower priority than the defaults, so it's pulling that in instead. I guess I need to put conda-forge higher up. That's kind of obnoxious...

that's what i was about to suggest

Okay, I guess this was user error, but it's pretty annoying that the defaults have a differently-built dependency.

The test from #7 should still probably be added as a legit test, though.

We only support conda-forge as a higher priority than defaults. That's how everything is built and tested at conda-forge. While one could try using a different configuration, they are on there own if they have issues.

Feel free to push defaults to build openblas in a compatible way though. Here's their recipe repo. TBH I think it would be good for both conda-forge and defaults if defaults simply reused our recipes for things they wish to still package. It would avoid many of these sorts of issues.

Library loading tests are generally a good idea. We should probably discuss having some standard way of doing this across all packages. Possibly it is worth having a baked in feature in conda-build for such a thing.