On Sat, May 5, 2012 at 2:16 PM, Jared Boone <ja...@sharebrained.com> wrote:
> I spent some time last night getting the the development branch of GNU Radio
> to compile on MacOS X 10.7. In the process, I saw some people having issues
> with compiler/assembler AVX support, Apple's ancient GPLv2 "as", and Xcode's
> LLVM. I succeeded in building and running GNU Radio using Xcode 4.3.2's tools
> (no MacPorts gcc, llvm, or cctools). I'm posting what I learned, in hopes
> somebody knows how to fix this from the GNU Radio source side (instead of
> patching CMake, as I did).
>
> The problem I saw, having to do with Clang compiler flag detection for ORC
> during cmake:
>
> -- Performing Test have_maltivec
> -- Performing Test have_maltivec - Success
> -- Performing Test have_mfpu_neon
> -- Performing Test have_mfpu_neon - Success
> -- Performing Test have_mfloat_abi_softfp
> -- Performing Test have_mfloat_abi_softfp - Success
> -- Performing Test have_funsafe_math_optimizations
> -- Performing Test have_funsafe_math_optimizations - Success
> ...
> -- Performing Test have_mpopcnt
> -- Performing Test have_mpopcnt - Success
>
> Note that I'm compiling on a Sandy Bridge Intel processor, so Altivec (PPC),
> NEON (ARM), and float-ABI (ARM?) aren't available. Also, LLVM 3.0 doesn't
> support -mpopcnt, and apparently doesn't support -munsafe_math_optimizations.
> And yet, the detections are showing "Success". Sure enough, when I "make",
> volk bombs out with:
>
> cc1: error: unrecognized command line option "-mfpu=neon"
> cc1: error: unrecognized command line option "-mfloat-abi=softfp"
>
> Examining build/volk/CMakeFiles/CMakeOutput.log, the command line executed
> for detecting the Altivec flag is:
>
> /usr/bin/c++ -Dhave_maltivec -maltivec -o
> CMakeFiles/cmTryCompileExec.dir/src.cxx.o -c
> /Users/jboone/tmp/gnuradio/build/volk/CMakeFiles/CMakeTmp/src.cxx
>
> Creating my own src.cxx ("int main() { return 0; }") and trying this out
> yields:
>
> clang: warning: argument unused during compilation: '-maltivec'
>
> Clang warns about the unrecognized flag, but CMake doesn't consider it an
> error. Why? Examining volk/lib/CMakeLists.txt, I see that CMake's
> CheckCXXCompilerFlag is included, and CHECK_CXX_COMPILER_FLAG is called with
> each flag to test.
>
> Looking at CMake's CHECK_CXX_COMPILER_FLAG, I see it tests the compiler's
> stdout (or stderr?) against these regular expressions:
>
> # Some compilers do not fail with a bad flag
> FAIL_REGEX "unrecognized .*option" # GNU
> FAIL_REGEX "unknown .*option" # Clang
> FAIL_REGEX "ignoring unknown option" # MSVC
> FAIL_REGEX "warning D9002" # MSVC, any lang
> FAIL_REGEX "[Uu]nknown option" # HP
> FAIL_REGEX "[Ww]arning: [Oo]ption" # SunPro
> FAIL_REGEX "command option .* is not recognized" # XL
> FAIL_REGEX "not supported in this configuration; ignored" # AIX
> FAIL_REGEX "File with unknown suffix passed to linker" # PGI
>
> None of these regex tests will catch the Clang warning above.
>
> My first inclination was to see if I could set a Clang flag (like "-Werror")
> to cause unused arguments to produce an error. But I can't tell how to do
> that with CMake. If somebody knows how to do this from within the GNU Radio
> sources, that would be ideal. Instead, I patched CMake as follows:
>
> --- /opt/local/share/cmake-2.8/Modules/CheckCXXCompilerFlag.cmake.orig
> 2012-05-04 23:41:16.000000000 -0700
> +++ /opt/local/share/cmake-2.8/Modules/CheckCXXCompilerFlag.cmake
> 2012-05-04 23:43:19.000000000 -0700
> @@ -29,6 +29,7 @@
> # Some compilers do not fail with a bad flag
> FAIL_REGEX "unrecognized .*option" # GNU
> FAIL_REGEX "unknown .*option" # Clang
> + FAIL_REGEX "argument unused during compilation" # Clang
> FAIL_REGEX "ignoring unknown option" # MSVC
> FAIL_REGEX "warning D9002" # MSVC, any lang
> FAIL_REGEX "[Uu]nknown option" # HP
>
> This results in more sensible flag detection for ORC during cmake:
>
> -- Performing Test have_maltivec
> -- Performing Test have_maltivec - Failed
> -- Performing Test have_mfpu_neon
> -- Performing Test have_mfpu_neon - Failed
> -- Performing Test have_mfloat_abi_softfp
> -- Performing Test have_mfloat_abi_softfp - Failed
> -- Performing Test have_funsafe_math_optimizations
> -- Performing Test have_funsafe_math_optimizations - Failed
> ...
> -- Performing Test have_mpopcnt
> -- Performing Test have_mpopcnt - Failed
> ...
> -- GCC missing xgetbv, Overruled arch avx
> -- Check size of void*[8]
> -- Check size of void*[8] - done
> -- CPU width is 64 bits, Overruled arch 32
> -- Available architectures:
> generic;64;3dnow;abm;mmx;sse;sse2;orc;norc;sse3;ssse3;sse4_a;sse4_1;sse4_2
> -- Available machines:
> generic_orc;sse2_64_orc;sse3_64_orc;ssse3_64_orc;sse4_1_64_orc
>
> ...and more importantly, I can compile GNU Radio and run gnuradio-companion.
>
> I see some similar patch history for CMake that suggests my fix is a good one:
>
> http://public.kitware.com/Bug/view.php?id=12394
>
> I looked at the CMake repository, and it looks like they haven't yet
> identified or fixed this problem:
>
>
> http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CheckCXXCompilerFlag.cmake;hb=HEAD
>
> So I'll submit a patch to CMake. Of course, until a new CMake is released,
> MacOS builders will run into this problem. So if anybody familiar with CMake
> knows a way to fix this from GNU Radio, that would be splendid!
>
> - Jared
Hi Jared,
Thanks for the information and reporting this. Obviously, this would
be a cmake patch issue, not ours, but hopefully helpful for people
working with GNU Radio in the same environment. Glad to hear you got
things working, though!
Tom
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
