gnuradio: VOLK component suggests compiling with gcc

[mf2k (Frank Schima)]

When building gnuradio, it says the following:

--->  Configuring gnuradio
WARNING: GNU Radio's VOLK component (which handles vector optimized instructions and routines) compiles best when using GCC.  The selected compiler is CLANG, which will result in a fully functioning GNU Radio install but the VOLK component will not utilize the CPU's capabilities.

So shouldn't this port have gccXY variants added?

[michaelld (Michael Dickens)]

Isn't this what configure.compiler is for? And, especially for ports where using a compiler brand (e.g., gcc, llvm, or clang) is what is important but not the actual compiler (e.g., macports-gcc-4.5)? I'd much prefer to not add a bunch of variants, one for each compiler type/version. I suppose I could add "+gcc", "+clang", and "+llvm" as variants and then internally select some version of gcc, clang, and llvm to do the job. But, again, using configure.compiler seems like a better way to go.

All of that said, sooner or later the GR folks will finish augmenting VOLK to work with clang and llvm; at that time this warning won't be necessary.

[mf2k (Frank Schima)]

Not sure what you mean here. Users should not be expected to know how to do this. We certainly don't support users adding portfile variables and having custom builds. That's why lots of other ports use +gccXY variants. See py27-numpy or atlas as an example. If you add a "+gcc" variant be sure to include the version like +gcc47 so that it conforms to Macports standards.

Anyway, this is a non-issue for me because I don't knowingly use gnuradio. It is simply a dependency on something else I have installed and I made a ticket because other ports have this issue and handle it by adding +gccXY variants. Feel free to close as wontfix, I'm just documenting the issue.

[ryandesign (Ryan Carsten Schmidt)]

Replying to michaelld@…:

I suppose I could add "+gcc", "+clang", and "+llvm" as variants

I do not recommend adding such variants. We don't typically do that.

Replying to macsforever2000@…:

That's why lots of other ports use +gccXY variants.

I know of no other ports that issue a message such as the one gnuradio issued. The reason why most of the ports that have gccXY variants have them is because they require a fortran compiler; that's not the reason here.

What is the consequence of VOLK not using the CPU to its fullest potential? If the consequences are bad, then consider adding "compiler.blacklist clang macports-clang-2.9 macports-clang-3.0 macports-clang-3.1 macports-clang-3.2 macports-clang-3.3" until such a time as they support clang properly; then MacPorts will build with llvm-gcc. If that too will not do, then add "llvm-gcc-4.2 macports-llvm-gcc-4.2" to compiler.blacklist; then MacPorts will use apple-gcc instead. Either way, add the block that jeremyhu has been adding to lots of ports lately to also add the proper compiler dependency, until such a time as #32542 is resolved.

[michaelld (Michael Dickens)]

If VOLK does not detect SSE[1/2/3/4], AVX, Neon, Altivec, or whatever SIMD instructions during configuration, then internally it will not compile kernels handling those instructions for the algorithms it encompasses (e.g., FIR filter). There is always a "generic" kernel, and if +orc is selected then ORC can be used as a kernel (which are not generally as good as GR's kernels, but anything is much better than generic). So, really, it's not such a big deal no matter which compiler is used. But, using Apple's GCC 4.2 is, right now, the optimal way to go until the GR folks get support for clang in place. If there is any change I would put in place is to just specify using this specific compiler; not +gccXY or +clangAB or whatnot.

[nospam2000 (Michael Dreher)]

Cc Me!

[kpreid (Kevin Reid)]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

Replying to michaelld@…:

But, using Apple's GCC 4.2 is, right now, the optimal way to go until the GR folks get support for clang in place. If there is any change I would put in place is to just specify using this specific compiler; not +gccXY or +clangAB or whatnot.

I would not recommend that, because it would unnecessarily install another copy of that compiler for users who already have it via Xcode 3. Instead, blacklist compilers that won't work, as I already mentioned above.

[michaelld (Michael Dickens)]

OK; I'll add the blacklist.

[cooljeanius (Eric Gallager)]

Cc Me!

[michaelld (Michael Dickens)]

Fixed in r109428 by blacklisting all non-Apple GCC compilers.