I think what’s going on here is that libgsl
is used cblas_caxpy
[1] but is not importing the library that defines it. Normally, with the two-level namespace, this would be a link-time error but one of the many drawbacks of the flat namespace is that it’s terrible at diagnosing such issues.
I used Xcode to build a test library that calls cblas_caxpy
and this is what I see:
% nm -m libQGSL.dylib | grep cblas_caxpy
(undefined) external _cblas_caxpy (from Accelerate)
% otool -L libQGSL.dylib
libQGSL.dylib:
/usr/local/lib/libQGSL.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.0.0)
/System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate (compatibility version 1.0.0, current version 4.0.0)
This library, which Xcode built using the two-level space as is the default, imports the symbol from Accelerate and imports Accelerate as a whole to resolve that symbol.
So, you may be able to work around this problem by explicitly linking Accelerate to your main executable. That’ll bring Accelerate into your process and that might be sufficient for its symbols to be available to resolve this flat namespace link request.
There’s a lot of uncertainly in the above because I never use the flat namespace. And, honestly, that’s my advice here: Stop using the flat namespace. It has many disadvantages, including much worse performance [2].
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] This is the C name for the function. At the linker level it gets a leading underscore for historical reasons. If you’re curious as to why…
https://stackoverflow.com/a/5908708
[2] At load time. Once the program is loading and running, performance should be roughly the same.