search

icecube / nuflux

A library for calculating atmospheric neutrino fluxes.
https://docs.icecube.aq/nuflux/main
GNU Lesser General Public License v3.0
15 stars 5 forks source link

Problems linking on macOS #7

Closed diaza closed 3 years ago

diaza commented 3 years ago

I'm building on my personal laptop, running macOS Catalina V10.15.7.

When I run ninja -C build I get the following error 

[11/15] Linking target libnuflux.dylib.
FAILED: libnuflux.dylib 
c++  -o libnuflux.dylib 'nuflux@sha/src_library_ANFlux.cpp.o' 'nuflux@sha/src_library_IPLEFlux.cpp.o' 'nuflux@sha/src_library_LegacyConventionalFlux.cpp.o' 'nuflux@sha/src_library_SplineFlux.cpp.o' 'nuflux@sha/src_library_SplineFlux2.cpp.o' 'nuflux@sha/src_library_FluxFunction.cpp.o' 'nuflux@sha/src_library_LegacyPromptFlux.cpp.o' 'nuflux@sha/src_library_logging.cpp.o' 'nuflux@sha/src_library_detail.cpp.o' -Wl,-dead_strip_dylibs -Wl,-undefined,error -Wl,-headerpad_max_install_names -shared -install_name @rpath/libnuflux.dylib /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/Accelerate.framework /usr/local/lib/libamd.dylib /usr/local/lib/libcamd.dylib /usr/local/lib/libccolamd.dylib /usr/local/lib/libcfitsio.dylib /usr/local/lib/libcholmod.dylib /usr/local/lib/libcolamd.dylib /usr/local/lib/libmetis.dylib /usr/local/lib/libphotospline.2.0.4.dylib /usr/local/lib/libspglam.2.0.4.dylib /usr/local/lib/libspqr.dylib /usr/local/lib/libsuitesparseconfig.dylib /usr/local/lib/libtbb.dylib /usr/local/lib/libtbbmalloc.dylib /usr/local/Cellar/cfitsio/3.490/lib/libcfitsio.dylib -Wl,-headerpad_max_install_names -Wl,-rpath,/usr/local/Cellar/cfitsio/3.490/lib
ld: can't map file, errno=22 file '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/Accelerate.framework' for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

I was able to fix this by going into build.ninja and appending every instance of /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/Accelerate.framework with -I.

kjmeagher commented 3 years ago

As near as I can tell this is an issue with the cmake files that photospline outputs. it sets the variable INTERFACE_LINK_LIBRARIES with the Acclerate.framework as if it were a shared library instead of a framework. I don't know how cmake creates those files so I am not sure how to fix this. Maybe @cnweaver has ideas.

cnweaver commented 3 years ago

Off of the top of my head I don't yet know what the issue is or how to fix it. It should not be necessary for code using photospline to explicitly link against the BLAS implementation. It's worth noting that the flags provided by photospline-config are to the best of my knowledge correct (I just tested linking a program which runs a spline fit using these and it worked without issue on my OS 10.15 system), and I would strongly recommend that interface over the weird CMake-specific stuff.

Digging further into this will require trying to do a similar test using CMake as the build system, which is significantly more work than it was to write the 3 line traditional makefile, and if that works, to test doing the exercise again with Meson, which I expect to be a similar further increase in complexity.

cnweaver commented 3 years ago

I've been able to test that, as expected, CMake can consume the configuration scripts that it produces for itself, but as reported, Meson cannot. This is consistent with the behavior documented for CMake, that "When a full path to a framework is used as a library, CMake will use a -framework A, and a -F to link the framework to the target." While this level of magic behavior is perhaps unwelcomely surprising, it seems to be working as intended; so I would tentatively classify this as a bug in Meson.