[MacPorts] #37979: gnuradio: VOLK component suggests compiling with gcc
#37979: gnuradio: VOLK component suggests compiling with gcc -------------------------------+------------------------- Reporter: macsforever2000@… | Owner: michaelld@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Keywords: | Port: gnuradio -------------------------------+------------------------- 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? -- Ticket URL: <https://trac.macports.org/ticket/37979> MacPorts <http://www.macports.org/> Ports system for Mac OS
#37979: gnuradio: VOLK component suggests compiling with gcc --------------------------------+------------------------- Reporter: macsforever2000@… | Owner: michaelld@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: gnuradio | --------------------------------+------------------------- Comment (by michaelld@…): 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. -- Ticket URL: <https://trac.macports.org/ticket/37979#comment:1> MacPorts <http://www.macports.org/> Ports system for Mac OS
#37979: gnuradio: VOLK component suggests compiling with gcc --------------------------------+------------------------- Reporter: macsforever2000@… | Owner: michaelld@… Type: enhancement | Status: new Priority: Low | Milestone: Component: ports | Version: Resolution: | Keywords: Port: gnuradio | --------------------------------+------------------------- Changes (by macsforever2000@…): * priority: Normal => Low Comment: 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. -- Ticket URL: <https://trac.macports.org/ticket/37979#comment:2> MacPorts <http://www.macports.org/> Ports system for Mac OS
#37979: gnuradio: VOLK component suggests compiling with gcc --------------------------------+------------------------- Reporter: macsforever2000@… | Owner: michaelld@… Type: enhancement | Status: new Priority: Low | Milestone: Component: ports | Version: Resolution: | Keywords: Port: gnuradio | --------------------------------+------------------------- Comment (by ryandesign@…): Replying to [comment:1 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 [comment:2 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. -- Ticket URL: <https://trac.macports.org/ticket/37979#comment:3> MacPorts <http://www.macports.org/> Ports system for Mac OS
#37979: gnuradio: VOLK component suggests compiling with gcc --------------------------------+------------------------- Reporter: macsforever2000@… | Owner: michaelld@… Type: enhancement | Status: new Priority: Low | Milestone: Component: ports | Version: Resolution: | Keywords: Port: gnuradio | --------------------------------+------------------------- Comment (by michaelld@…): 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. -- Ticket URL: <https://trac.macports.org/ticket/37979#comment:4> MacPorts <http://www.macports.org/> Ports system for Mac OS
#37979: gnuradio: VOLK component suggests compiling with gcc --------------------------------+------------------------- Reporter: macsforever2000@… | Owner: michaelld@… Type: enhancement | Status: new Priority: Low | Milestone: Component: ports | Version: Resolution: | Keywords: Port: gnuradio | --------------------------------+------------------------- Comment (by ryandesign@…): Replying to [comment:4 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. -- Ticket URL: <https://trac.macports.org/ticket/37979#comment:7> MacPorts <http://www.macports.org/> Ports system for OS X
#37979: gnuradio: VOLK component suggests compiling with gcc --------------------------------+------------------------- Reporter: macsforever2000@… | Owner: michaelld@… Type: enhancement | Status: new Priority: Low | Milestone: Component: ports | Version: Resolution: | Keywords: Port: gnuradio | --------------------------------+------------------------- Comment (by michaelld@…): OK; I'll add the blacklist. -- Ticket URL: <https://trac.macports.org/ticket/37979#comment:8> MacPorts <http://www.macports.org/> Ports system for OS X
#37979: gnuradio: VOLK component suggests compiling with gcc --------------------------------+------------------------- Reporter: macsforever2000@… | Owner: michaelld@… Type: enhancement | Status: closed Priority: Low | Milestone: Component: ports | Version: Resolution: fixed | Keywords: Port: gnuradio | --------------------------------+------------------------- Changes (by michaelld@…): * status: new => closed * resolution: => fixed Comment: Fixed in r109428 by blacklisting all non-Apple GCC compilers. -- Ticket URL: <https://trac.macports.org/ticket/37979#comment:10> MacPorts <http://www.macports.org/> Ports system for OS X
participants (1)
-
MacPorts