Build fail using clang on OSX 10.8 and fix

GNU Radio
1

Running Mac OS X 10.8.2, XCode 4.5.1, Apple clang 4.1. On both the
current master and next, I get the same error when building. Compiling
both the master and next works fine using gcc (both apple gcc 4.2, and
apple llvm gcc 4.2).

{{{
[ 5%] Building C object
gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/float_dotprod_sse64.S.o
cd /opt/GNURadio/source/builds/next_clang/gnuradio-core/src/lib &&
/usr/bin/clang -Dgnuradio_core_EXPORTS -DHAVE_NETDB_H -DHAVE_SYS_TIME_H
-DHAVE_SYS_TYPES_H -DHAVE_SYS_SELECT_H -DHAVE_SYS_SOCKET_H
-DHAVE_SYS_MMAN_H -DHAVE_SYS_IPC_H -DHAVE_SYS_SHM_H -DHAVE_SIGNAL_H
-DHAVE_NETINET_IN_H -DHAVE_ARPA_INET_H -DHAVE_UNISTD_H -DHAVE_SNPRINTF
-DHAVE_SIGACTION -DHAVE_SELECT -DHAVE_SYSCONF -DHAVE_GETPAGESIZE
-DHAVE_NANOSLEEP -DHAVE_GETTIMEOFDAY -DHAVE_POSIX_MEMALIGN
-DALIGNED_MALLOC=0 -DHAVE_PTHREAD_SIGMASK -DHAVE_SINF -DHAVE_COSF
-DHAVE_MMAP -DTRY_SHM_VMCIRCBUF -DFFTW3F_THREADS -O3 -DNDEBUG -fPIC
-I/opt/GNURadio/source/git/gnuradio-core/src/lib/hier
-I/opt/GNURadio/source/git/gruel/src/include
-I/opt/GNURadio/source/builds/next_clang/gruel/src/include
-I/opt/local/include
-I/opt/GNURadio/source/git/gnuradio-core/src/lib/runtime
-I/opt/GNURadio/source/builds/next_clang/gnuradio-core/src/lib/general
-I/opt/GNURadio/source/git/gnuradio-core/src/lib/general
-I/opt/GNURadio/source/builds/next_clang/gnuradio-core/src/lib/gengen
-I/opt/GNURadio/source/git/gnuradio-core/src/lib/gengen
-I/opt/GNURadio/source/builds/next_clang/gnuradio-core/src/lib/filter
-I/opt/GNURadio/source/git/gnuradio-core/src/lib/filter
-I/opt/GNURadio/source/git/gnuradio-core/src/lib/missing
-I/opt/GNURadio/source/git/gnuradio-core/src/lib/reed-solomon
-I/opt/GNURadio/source/git/gnuradio-core/src/lib/viterbi
-I/opt/GNURadio/source/git/gnuradio-core/src/lib/io
-I/opt/GNURadio/source/builds/next_clang/gnuradio-core/src/lib/swig
-I/opt/GNURadio/source/git/gnuradio-core/src/lib/swig
-I/opt/GNURadio/source/git/volk/include
-I/opt/GNURadio/source/builds/next_clang/volk/include -o
CMakeFiles/gnuradio-core.dir/filter/float_dotprod_sse64.S.o -c
/opt/GNURadio/source/git/gnuradio-core/src/lib/filter/float_dotprod_sse64.S
/opt/GNURadio/source/git/gnuradio-core/src/lib/filter/float_dotprod_sse64.S:57:2:
error: unknown directive
.version “01.01”
^
}}}

The actual assembly directive that is causing this issue is:

.version “01.01”

which if I comment it out of all of the necessary files then clang seems
to work. Do we really require this specific directive in those assembly
files? - MLD

2

On Mon, Nov 5, 2012 at 3:05 PM, Michael D. [email protected]
wrote:

The actual assembly directive that is causing this issue is:

    .version        "01.01"

which if I comment it out of all of the necessary files then clang seems to
work. Do we really require this specific directive in those assembly files? - MLD

Hey Michael,

I just tested that on my Linux machine and nothing seems to suffer for
it. I doubt that we require it. I’ve just posted this branch on my
github repo “git://github.com/trondeau/gnuradio.git” called
asm_for_clang.

This shouldn’t be an issue with the next branch, though, since we’ve
removed that filter code as it’s all replaced by gr-filter.

Tom

3

On Nov 5, 2012, at 5:21 PM, Tom R. [email protected] wrote:

I just tested that on my Linux machine and nothing seems to suffer for
it. I doubt that we require it. I’ve just posted this branch on my
github repo “git://github.com/trondeau/gnuradio.git” called
asm_for_clang.

This shouldn’t be an issue with the next branch, though, since we’ve
removed that filter code as it’s all replaced by hr-filter.

Yup; somehow I buffed the relative path for my “next” checkout; it seems
to compile using clang without those changes. Whew. I thought I
remembered this issue being fixed; so, I’m not entirely crazy after all!
Thanks! - MLD

4

On Mon, Nov 5, 2012 at 6:31 PM, Michael D. [email protected]
wrote:

On Nov 5, 2012, at 5:21 PM, Tom R. [email protected] wrote:

I just tested that on my Linux machine and nothing seems to suffer for
it. I doubt that we require it. I’ve just posted this branch on my
github repo “git://github.com/trondeau/gnuradio.git” called
asm_for_clang.

This shouldn’t be an issue with the next branch, though, since we’ve
removed that filter code as it’s all replaced by hr-filter.

Yup; somehow I buffed the relative path for my “next” checkout; it seems to
compile using clang without those changes. Whew. I thought I remembered this
issue being fixed; so, I’m not entirely crazy after all! Thanks! - MLD

Great, good to know.

If that branch with the patch for master is working for everyone, I’ll
merge it into master. We obviously want our 3.6 versions to continue
to work as well as possible even if we are migrating away from that
particularly troublesome code.

Tom