# Build fail using clang on OSX 10.8 and fix **URL:** \ **Category:** GNU Radio\ **Created:** [November 5, 2012, 9:06pm UTC](https://www.ruby-forum.com/t/build-fail-using-clang-on-osx-10-8-and-fix/224260 "2012-11-05T21:06:32Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![aris](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/258eb7/32.png) [@aris](https://www.ruby-forum.com/u/aris)\ **Post date:** [November 5, 2012, 9:06pm UTC](https://www.ruby-forum.com/t/build-fail-using-clang-on-osx-10-8-and-fix/224260/1 "2012-11-05T21:06:32Z")
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 ---
**Author:** ![mdeering](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/278dde/32.png) [@mdeering](https://www.ruby-forum.com/u/mdeering)\ **Post date:** [November 5, 2012, 11:22pm UTC](https://www.ruby-forum.com/t/build-fail-using-clang-on-osx-10-8-and-fix/224260/2 "2012-11-05T23:22:42Z")
On Mon, Nov 5, 2012 at 3:05 PM, Michael D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 ---
**Author:** ![mdeering](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/278dde/32.png) [@mdeering](https://www.ruby-forum.com/u/mdeering)\ **Post date:** [November 6, 2012, 12:32am UTC](https://www.ruby-forum.com/t/build-fail-using-clang-on-osx-10-8-and-fix/224260/3 "2012-11-06T00:32:21Z")
On Nov 5, 2012, at 5:21 PM, Tom R. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 ---
**Author:** ![mdeering](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/278dde/32.png) [@mdeering](https://www.ruby-forum.com/u/mdeering)\ **Post date:** [November 6, 2012, 4:31pm UTC](https://www.ruby-forum.com/t/build-fail-using-clang-on-osx-10-8-and-fix/224260/4 "2012-11-06T16:31:43Z")
On Mon, Nov 5, 2012 at 6:31 PM, Michael D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > On Nov 5, 2012, at 5:21 PM, Tom R. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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