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 ?
Fixed! Thanks @jschueller / @jakirkham.
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.