Recent Commit Issue

Regarding commit c0b3ce38db0eaaca05fe2f45827fcf6c9184b72b “wavelet: fix
for -lgslcblas getting stripped out of the link flags due to
-Wl,–as-needed default on newer gcc toolchains, results in missing blas
symbols at runtime”, as well as other assumptions being made about GCC:

Just because the compiler is GCC does not mean it will accept the flag
being passed to it, nor that it is guaranteed to provide specific
functionality if >= a specific version. Maybe this works on Linux, but
it does not on Mac OS X using either Apple’s or MacPorts’ GCC (4.2, 4.6,
4.7). So, the above “-Wl,–no-as-needed” does not work, nor does the
“xgetbv” instruction, because all versions of GCC use Apple’s assembler
(which does not support these features).

Clang as provided by Xcode or MacPorts does -not- use Apple’s assembler,
which means it should be multi-OS compatible for flags and instructions
– but:

The best way to check for a feature (compiler flag, or specific
instruction) is to actually test for it, just like we do for most other
compiler flags, headers, and many functions (both OS-provided and other
dependencies).

Thanks for listening. I’m patching the MacPorts install of GNU Radio to
remove this commit until a better solution is found. - MLD

I think this is a sort of different beast. You could check for gslcblas
and even pass -lgslcblas as a compile flag, in fact that is what is
going
on. The problem is GSL needs BLAS but does not call it directly from
the
object file, and the --as-needed doesnt check for symbols recursively,
so
doesnt link it, even if you specifically pass -lgslcblas as a parameter.
I
suppose one option is to directly link the gr-wavelet library to CBLAS,
which honestly I thought was already happening.

Tim