gnuradio fails to build on 10.9

[ken@…]

 Building gnuradio
Error: org.macports.build for port gnuradio returned: command execution failed
Please see the log file for port gnuradio for details:
    /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_gnuradio/gnuradio/main.log
To report a bug, follow the instructions in the guide:
    http://guide.macports.org/#project.tickets
Error: Processing of port gnuradio failed

[ryandesign (Ryan Carsten Schmidt)]

The relevant part of the log seems to be "latex: command not found"

[michaelld (Michael Dickens)]

The relevant issue is when linking "libgnuradio-runtime.3.7.1.dylib", a bunch of undefined symbols.

:info:build Undefined symbols for architecture x86_64:
:info:build   "boost::filesystem::path_traits::dispatch(boost::filesystem::directory_entry const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> >&, std::codecvt<wchar_t, char, __mbstate_t> const&)", referenced from:
:info:build       boost::filesystem::path::path<boost::filesystem::directory_entry>(boost::filesystem::directory_entry const&, boost::enable_if<boost::filesystem::path_traits::is_pathable<boost::decay<boost::filesystem::directory_entry>::type>, void>::type*)in prefs.cc.o
[snip]

I'll be working on this tomorrow morning. It has something to do with libc++ versus libstdc++, I'll bet.

[bloessl@…]

Cc Me!

[michaelld (Michael Dickens)]

has duplicate #41170.

I'm working on this issue today. Hopefully it will have a quick resolution like uhd-devel did :)

[i.am@…]

Cc Me!

[michaelld (Michael Dickens)]

Interesting: my build of gnuradio-devel gets past the error in this ticket, but then dies trying to compile SWIG-generated C++. Maybe try:

sudo port -f uninstall boost
sudo port install boost
sudo port install gnuradio-devel

and see if that helps. Make sure to add on any variants you want when installing.

[ken@…]

Replying to michaelld@…:

Interesting: my build of gnuradio-devel gets past the error in this ticket, but then dies trying to compile SWIG-generated C++. Maybe try:

sudo port -f uninstall boost
sudo port install boost
sudo port install gnuradio-devel

and see if that helps. Make sure to add on any variants you want when installing.

I have uninstalled boost library and reinstalled and it still failed (I installed gnuradio, not gnuradio-devel). I to was failing on a lot of the dependencies, but after fulling removing macports, updating to mavericks version of ports and then re-installing I was able to build all the dependencies. GNURadio

I don't believe it is a problem with boost.

[michaelld (Michael Dickens)]

Thanks for trying. Even if you did get past the first boost issue, you'd get to the SWIG one, which isn't easily fixable -- we can't patch SWIG-generated code, since it is created during runtime. SWIG has a ​ticket open with this issue since August 27; it has LOTS of tickets open right now with various issue, and while I'm sure the SWIG programmers are making progress, it does not seem to be very fast.

I think the "best" solution right now to get GNU Radio working with 10.9 is to uninstall -everything- and rebuild from go using libstdc++ (the default in 10.9 is to use Apple's new libc++). I'm not sure how to do that yet; I'll experiment today & post back once I've figured it out. I will also post about this issue to the broad GR list.

[venkyne1984@…]

Cc Me!

[jboone (Jared Boone)]

Cc Me!

[michaelld (Michael Dickens)]

There is no way to use libstdc++; it just will not work in the manner I had hoped.

That said, the issue is that SWIG is not generating C++11 compliant code. If I disable SWIG (and, thus GRC), GNU Radio compiles just fine using libc++. I don't know enough about SWIG to be useful in trying to debug what it's doing, and they have a lot of tickets open so it does not look to me like there's much progress being made to update SWIG to generate C++11 compliant code. Hopefully I'm wrong :)

[ken@…]

Can you explain how you got past the boost errors?

[michaelld (Michael Dickens)]

Nope. It just worked for me. I've no idea why.

[michaelld (Michael Dickens)]

A guess: I used the SVN trunk of MacPorts, which contains changes specific for 10.9 that are not in the latest release. If anyone wants to be brave and try out the SVN trunk on this issue that might prove interesting. I tend to believe the right way to do this is:

sudo port -f uninstall installed
sudo port clean all

follow the ​instructions to install from SVN trunk, including the optional one. Then:

sudo port install gnuradio-devel +gcc48 +atlas

which will take a long time.

Or, wait until the release of port 2.2.2 or 2.3.0 (I'm not sure of the numbering, nor the release date).

[michaelld (Michael Dickens)]

I just pushed r113092, which allows GNU Radio to be compiled in 10.9, but without the SWIG interface; which means no gnuradio-companion. If you try to enable +grc or +swig, the install will error out in 10.9 only. Otherwise, it builds and passes "make test". This feature set (just the C++ API and runtime) is desirable to some GNU Radio users. I will play with SWIG to see if there's an "easy" fix to the issues we're encountering.

[acb@…]

Cc Me!

[carlesfernandez (Carles Fernandez)]

Cc Me!

[DanielO (Daniel O'Connor)]

Cc Me!

[michaelld (Michael Dickens)]

I just pushed r113379, which should fix installing GNU Radio all around. Please let me know if/how this works for you, after doing "sudo port selfupdate" or whatever your poison is for getting dports updates.

[acb@…]

Works for me. Thanks!

[carlesfernandez (Carles Fernandez)]

Also worked for me for gnuradio-devel (Macports 2.2.1, no svn).

Thanks Michael!

[ken@…]

Didn't work for me, uploading log.

[michaelld (Michael Dickens)]

@ken: Try the following:

sudo port -f uninstall boost log4cpp
sudo port clean gnuradio
sudo port selfupdate
sudo port install gnuradio

and see if that works. Hopefully it will take care of your linking issue.

[ken@…]

Replying to michaelld@…:

@ken: Try the following:

sudo port -f uninstall boost log4cpp
sudo port clean gnuradio
sudo port selfupdate
sudo port install gnuradio

and see if that works. Hopefully it will take care of your linking issue.

This didn't work

[michaelld (Michael Dickens)]

OK; what happened? Did boost and log4cpp get installed? If so, did the error change as to why gnuradio didn't work?

[ken@…]

Replying to michaelld@…:

OK; what happened? Did boost and log4cpp get installed? If so, did the error change as to why gnuradio didn't work?

Nothing changed. Error is still the same and everything installed fine. I removed all dependencies of gnu-radio and re-installed from go.

[jboone (Jared Boone)]

First, thank you Michael for all your work maintaining this port! It's greatly appreciated.

Overnight, I tried completely deleting /opt and other MacPorts bits and installing the SVN version of MacPorts according to the MacPorts guide (​http://guide.macports.org/#installing.macports.subversion), including the optional step. I did an "svn update" in /opt/mports/trunk (r113404 as of now), and a "portindex" in /opt/mports/trunk/dports. I then ran "sudo port install gnuradio-devel". After several hours, I get the same Boost error while compiling gnuradio-devel. See the main.log I'll post momentarily.

I will try what you advised for Ken (comment 26), but I'm not optimistic it will help.

[jboone (Jared Boone)]

Built from SVN late last night, after deleting all MacPorts bits I could find.

[michaelld (Michael Dickens)]

If it's any consolation, I'm seeing the error now too :) I'm working on it; I'm pretty sure I know the cause, just not the fix.

[michaelld (Michael Dickens)]

The issue is that boost and gnuradio need to be build using the same compiler. But, clang on 10.9 does not always build volk; or, something like that. I reverted r113388, which should take care of the immediate problem for some people. But, for others the build will die trying to compile volk. For those folks, I need to know what "/usr/bin/clang -v" returns.

[jboone (Jared Boone)]

You called it. I tried again, and it looks like I have the clang issue. I was seeing this earlier -- some problem with an intrinsic. Log attached in a moment.

$ sudo bash
Password:

# cd /opt/mports/trunk/

# svn update
Updating '.':
D    dports/gnome/libsoup/files
U    dports/gnome/libsoup/Portfile
U    dports/science/gnuradio/Portfile
Updated to revision 113407.

$ sudo port -f uninstall boost log4cpp
--->  Unable to uninstall boost @1.54.0_0+no_single+no_static+python27, the following ports depend on it:
--->  	uhd @release_003_005_004_0+docs+examples+full+libusb+manual+python27+test
Warning: Uninstall forced.  Proceeding despite dependencies.
--->  Deactivating boost @1.54.0_0+no_single+no_static+python27
--->  Unable to deactivate boost @1.54.0_0+no_single+no_static+python27, the following ports depend on it:
--->  	uhd @release_003_005_004_0+docs+examples+full+libusb+manual+python27+test
Warning: Deactivate forced.  Proceeding despite dependencies.
--->  Cleaning boost
--->  Uninstalling boost @1.54.0_0+no_single+no_static+python27
--->  Cleaning boost
--->  Deactivating log4cpp @1.1_0
--->  Cleaning log4cpp
--->  Uninstalling log4cpp @1.1_0
--->  Cleaning log4cpp

$ sudo port clean gnuradio
--->  Cleaning gnuradio

$ sudo port install gnuradio
...
Error: org.macports.build for port gnuradio returned: command execution failed
Please see the log file for port gnuradio for details:
    /opt/local/var/macports/logs/_opt_mports_trunk_dports_science_gnuradio/gnuradio/main.log
To report a bug, follow the instructions in the guide:
    http://guide.macports.org/#project.tickets
Error: Processing of port gnu radio failed

$ /usr/bin/clang -v
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.0.0
Thread model: posix

[jboone (Jared Boone)]

Rebuild with backed-out commit to avoid clang issue -- yep, clang issue is back.

[ken@…]

sudo port clean gnuradio
sudo port selfupdate
sudo port install gnuradio

Build failed

Kens-MacBook-Pro:~ Ken$ /usr/bin/clang -v

Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)

Target: x86_64-apple-darwin13.0.0

Thread model: posix

[michaelld (Michael Dickens)]

Yeah; that's the clang/volk issue with older clang. Is your install of Xcode fully updated? On my 10.9 install, I have the same "clang -v" but it makes it through the build OK. My Xcode is the latest. Also, could you try the following:

sudo port clean gnuradio
sudo port install gnuradio configure.compiler=macports-clang-3.4

and see if that works; it does for me. Obviously this will install clang 3.4, which might take a while if the binary download is not available.

[roysn@…]

snaff:dump1090 roy$ sudo port install gnuradio configure.compiler=macports-clang-3.4
--->  Computing dependencies for gnuradio
--->  Dependencies to be installed: clang-3.4 clang_select llvm-3.4
Error: The following dependencies were not installed: clang-3.4 clang_select llvm-3.4
To report a bug, follow the instructions in the guide:
    http://guide.macports.org/#project.tickets
Error: Processing of port gnuradio failed

[michaelld (Michael Dickens)]

Fair enough; I guess you need to do:

sudo port install clang-3.4
sudo port install gnuradio configure.compiler=macports-clang-3.4

[michaelld (Michael Dickens)]

I'm also wondering what the following returns for folks, both those having success and those failing:

xcodebuild -version
/usr/bin/clang -v
uname -a
sysctl machdep.cpu.brand_string machdep.cpu.features

[acb@…]

Michael -

A success case:

$ xcodebuild -version Xcode 5.0.2

$ /usr/bin/clang -v Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) Target: x86_64-apple-darwin13.0.0 Thread model: posix

$ uname -a Darwin acb_imac 13.0.0 Darwin Kernel Version 13.0.0: Thu Sep 19 22:22:27 PDT 2013; root:xnu-2422.1.72~6/RELEASE_X86_64 x86_64

$ sysctl machdep.cpu.brand_string machdep.cpu.features machdep.cpu.brand_string: Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz machdep.cpu.features: FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM PBE SSE3 DTES64 MON DSCPL VMX SMX EST TM2 SSSE3 CX16 TPR PDCM SSE4.1 XSAVE

Thanks for all the hard work on this!

• Art

[michaelld (Michael Dickens)]

Thanks, Art. And, you're welcome! You have the same setup as my 10.9 box, which does not have AVX and hence does not have this issue. I'm thinking the "machdep.cpu.features" of failures will be the ones which include "AVX1.0" (or, newer). I'm going to try booting 10.9 on my other computer, which is more recent and thus has this feature.

[jboone (Jared Boone)]

Michael, I appreciate your patience. :-)

I should mention that Software Update was acting weird when I got my latest Xcode update a few days ago. It would show app updates downloading (including Xcode), then not, then yes. But when I open Xcode now, it reports "Version 5.0.2 (5A3005)", so it seems fine.

Here's other details you've requested:

$ which clang
/usr/bin/clang

$ xcodebuild -version
Xcode 5.0.2
Build version 5A3005

$ /usr/bin/clang -v
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.0.0
Thread model: posix

$ uname -a
Darwin earfeast-laptop.local 13.0.0 Darwin Kernel Version 13.0.0: Thu Sep 19 22:22:27 PDT 2013; root:xnu-2422.1.72~6/RELEASE_X86_64 x86_64

$ sysctl machdep.cpu.brand_string machdep.cpu.features
machdep.cpu.brand_string: Intel(R) Core(TM) i7-2720QM CPU @ 2.20GHz
machdep.cpu.features: FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM PBE SSE3 PCLMULQDQ DTES64 MON DSCPL VMX SMX EST TM2 SSSE3 CX16 TPR PDCM SSE4.1 SSE4.2 x2APIC POPCNT AES PCID XSAVE OSXSAVE TSCTMR AVX1.0

Sure enough, "AVX1.0" is in there. This is a MacBook Pro from approximately March 2011 -- Sandy Bridge, I believe.

I must also mention that I can't do the command-line tools update (recommended by the MacPorts Guide) for some reason:

xcode-select --install

A dialog reports "Can't install the software because it is not currently available from the Software Update server."

I tried the Apple-recommended means of installing the Command Line Tools from within Xcode (​https://developer.apple.com/support/xcode/) and I don't even see an option to install the Command Line Tools. It appears they moved it to the "Locations" area of the Xcode Preferences. In that tab, my Command Line Tools are "Xcode 5.0.2 (5A3005)", and is the only option in the combo box. All that said, I'm not sure clang comes in the Command Line Tools. If it lives in /usr/bin, maybe it comes with the OS?

I re-downloaded and re-installed the "Command Line Tools (OS X Mavericks) for Xcode - Late October", dated Oct 22, 2013. I don't see anything more recent, which may be why the command-line install technique above isn't working? There was no effect on clang -v -- the same as above.

At this point, I tried what you suggested above (and realize now that with all the stuff I just did, I kinda ignored the scientific method):

$ sudo port clean gnuradio
Password:
--->  Cleaning gnuradio

$ sudo port install clang-3.4
--->  Computing dependencies for clang-3.4
--->  Dependencies to be installed: clang_select llvm-3.4
...
--->  Cleaning clang-3.4
--->  Updating database of binaries: 100.0%
--->  Scanning binaries for linking errors: 58.1%
Warning: /opt/local/bin/i686-apple-darwin13-llvm-cpp-4.2 uses /usr/lib/libstdc++.6.dylib as C++ standard library although macports::cxx_stdlib is set to libc++.
--->  Scanning binaries for linking errors: 58.2%
Warning: /opt/local/bin/i686-apple-darwin13-llvm-g++-4.2 uses /usr/lib/libstdc++.6.dylib as C++ standard library although macports::cxx_stdlib is set to libc++.
--->  Scanning binaries for linking errors: 58.3%
Warning: /opt/local/bin/i686-apple-darwin13-llvm-gcc-4.2 uses /usr/lib/libstdc++.6.dylib as C++ standard library although macports::cxx_stdlib is set to libc++.
--->  Scanning binaries for linking errors: 58.5%
Warning: /opt/local/bin/llvm-gcov-4.2 uses /usr/lib/libstdc++.6.dylib as C++ standard library although macports::cxx_stdlib is set to libc++.
--->  Scanning binaries for linking errors: 58.8%
Warning: /opt/local/libexec/llvm-gcc42/gcc/i686-apple-darwin13/4.2.1/cc1 uses /usr/lib/libstdc++.6.dylib as C++ standard library although macports::cxx_stdlib is set to libc++.
--->  Scanning binaries for linking errors: 58.8%
Warning: /opt/local/libexec/llvm-gcc42/gcc/i686-apple-darwin13/4.2.1/cc1obj uses /usr/lib/libstdc++.6.dylib as C++ standard library although macports::cxx_stdlib is set to libc++.
--->  Scanning binaries for linking errors: 58.9%
Warning: /opt/local/libexec/llvm-gcc42/gcc/i686-apple-darwin13/4.2.1/cc1objplus uses /usr/lib/libstdc++.6.dylib as C++ standard library although macports::cxx_stdlib is set to libc++.
--->  Scanning binaries for linking errors: 59.0%
Warning: /opt/local/libexec/llvm-gcc42/gcc/i686-apple-darwin13/4.2.1/cc1plus uses /usr/lib/libstdc++.6.dylib as C++ standard library although macports::cxx_stdlib is set to libc++.
--->  Scanning binaries for linking errors: 59.0%
Warning: /opt/local/libexec/llvm-gcc42/gcc/i686-apple-darwin13/4.2.1/collect2 uses /usr/lib/libstdc++.6.dylib as C++ standard library although macports::cxx_stdlib is set to libc++.
--->  Scanning binaries for linking errors: 59.1%
Warning: /opt/local/libexec/llvm-gcc42/gcc/i686-apple-darwin13/4.2.1/libllvmgcc.dylib uses /usr/lib/libstdc++.6.dylib as C++ standard library although macports::cxx_stdlib is set to libc++.
--->  Scanning binaries for linking errors: 100.0%
--->  No broken files found.

$ sudo port install gnuradio configure.compiler=macports-clang-3.4
...
--->  Building gnuradio
--->  Staging gnuradio into destroot
--->  Installing gnuradio @3.7.2_0+docs+grc+jack+orc+portaudio+python27+qtgui+sdl+swig+uhd+wavelet+wxgui
--->  Activating gnuradio @3.7.2_0+docs+grc+jack+orc+portaudio+python27+qtgui+sdl+swig+uhd+wavelet+wxgui
--->  Cleaning gnuradio
...
(more cxx_stdlib warnings)
...

Success! Inside Python, I can "import gnuradio" and "from gnuradio import gr". Trying to run gnuradio-companion, I've just discovered my XQuartz is broken somehow, so I'm fixing that now... FWIW, it looks like a new version of XQuartz is out -- I had 2.7.4, but there's now 2.7.5, which I'm installing now. And... GRC runs! Thanks! Hopefully, the magic of making the port work smoothly with the latest compiler won't be too difficult...

[ken@…]

Thanks, changing the compiler worked.

[cscott@…]

I'm seeing a SIGSEGV any time I try to run top_block.py. Unfortunately, it only spits out "Warning: failed to XInitThreads()" as a hint to what's going on.

I've tried many combinations of blocks and it segmentation faults every time. :(

[cscott@…]

Cc Me!

[konstanty@…]

Since using

sudo port install clang-3.4
sudo port install gnuradio configure.compiler=macports-clang-3.4

everything compiles OK, including gnuradio-companion (and it's useable as a program) - however as mentioned by cscott above, running anything related to gnuradio results in a SIGSEGV - Even if the Wx and Qt related options are removed.

The information requested above - the AVX1.0 is here.

$ xcodebuild -version
Xcode 5.0.2
Build version 5A3005

$ /usr/bin/clang -v
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.0.2
Thread model: posix

$ uname -a
Darwin konstantys-mbp.lan 13.0.2 Darwin Kernel Version 13.0.2: Sun Sep 29 19:38:57 PDT 2013; root:xnu-2422.75.4~1/RELEASE_X86_64 x86_64

$ sysctl machdep.cpu.brand_string machdep.cpu.features
machdep.cpu.brand_string: Intel(R) Core(TM) i7-4850HQ CPU @ 2.30GHz
machdep.cpu.features: FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM PBE SSE3 PCLMULQDQ DTES64 MON DSCPL VMX SMX EST TM2 SSSE3 FMA CX16 TPR PDCM SSE4.1 SSE4.2 x2APIC MOVBE POPCNT AES PCID XSAVE OSXSAVE SEGLIM64 TSCTMR AVX1.0 RDRAND F16C

and the working compiler .. (compile works, but cannot execute flow graphs)

$ /opt/local/bin/clang-mp-3.4 -v
clang version 3.4 (trunk 193941)
Target: x86_64-apple-darwin13.0.2
Thread model: posix

[acb@…]

Yep. While I did get a clean build now (on my older Mini sans AVX) when I launch GRC I get this:

acb_imac:~ acb$ gnuradio-companion
Warning: Block key "blocks_ctrlport_monitor_performance" not found when loading category tree.
Warning: Block key "blocks_ctrlport_monitor_performance" not found when loading category tree.
Mac OS; Clang version 5.0 (clang-500.2.79); Boost_105400; UHD_003.005.004-0-unknown

<<< Welcome to GNU Radio Companion 3.7.2 >>>

Loading: "/Users/acb/Desktop/basic_wbfm.grc"
>>> Done

Showing: "/Users/acb/Desktop/basic_wbfm.grc"

And then when I launch that particular flowgraph I get:

Generating: "/Users/acb/Desktop/top_block.py"

Executing: "/Users/acb/Desktop/top_block.py"

Mac OS; Clang version 5.0 (clang-500.2.79); Boost_105400; UHD_003.005.004-0-unknown

Warning: failed to XInitThreads()
2013-11-16 16:42:57.576 Python[48715:507] CoreText performance note: Client called CTFontCreateWithName() using name ".Lucida Grande UI" and got font with PostScript name ".LucidaGrandeUI". For best performance, only use PostScript names when calling this API.
2013-11-16 16:42:57.577 Python[48715:507] CoreText performance note: Set a breakpoint on CTFontLogSuboptimalRequest to debug.
2013-11-16 16:42:57.649 Python[48715:507] CoreText performance note: Client called CTFontCreateWithName() using name ".Lucida Grande UI" and got font with PostScript name ".LucidaGrandeUI". For best performance, only use PostScript names when calling this API.
Using Volk machine: sse4_1_64_orc
2013-11-16 16:42:58.468 Python[48715:507] CoreText performance note: Client called CTFontCreateWithName() using name ".Lucida Grande UI" and got font with PostScript name ".LucidaGrandeUI". For best performance, only use PostScript names when calling this API.
2013-11-16 16:42:58.481 Python[48715:507] CoreText performance note: Client called CTFontCreateWithName() using name ".Lucida Grande UI" and got font with PostScript name ".LucidaGrandeUI". For best performance, only use PostScript names when calling this API.
gr-osmosdr v0.1.0-44-g0d10f5e9 (0.1.1git) gnuradio 3.7.2
built-in source types: file fcd rtl rtl_tcp uhd hackrf netsdr 

Whereafter it seems to work, but it's worrisome. Seems like maybe several different things happening at once.

• Art

[michaelld (Michael Dickens)]

@Art: The warnings are normal behavior when starting GRC these days. I don't know about the CoreText notes; never seen those before. The big issue is whether GNU Radio actually works for you, whether flow graphs can be executed. If they work, then all is well.

I'm working on the other issues with the remaining folks; I'm not sure of a solution yet for the SIGSEGV issue. I am glad that using clang 3.4 is working for at least some people; there is hope!

[michaelld (Michael Dickens)]

The "Warning: failed to XInitThreads()" is normal these days; just ignore it, as it does no harm either. I'll look into putting and #ifdef around it so that it is not ever tried on Darwin/OSX.

[slarew]

Cc Me!

[lqfmickey@…]

Cc Me!

[lqfmickey@…]

Hello Michael, I rebuild the gnuradio with clang-3.4. Everything compiles fine, but GRC is not installed.

Here's details:

$ which clang
/usr/bin/clang

$ xcodebuild -version
Xcode 5.0.2
Build version 5A3005

$ /usr/bin/clang -v
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.0.0
Thread model: posix

$ uname -a
Darwin lqf-server.local 13.0.0 Darwin Kernel Version 13.0.0: Thu Sep 19 22:22:27 PDT 2013; root:xnu-2422.1.72~6/RELEASE_X86_64 x86_64

$ sysctl machdep.cpu.brand_string machdep.cpu.features
machdep.cpu.brand_string: Intel(R) Core(TM) i7-3820QM CPU @ 2.70GHz
machdep.cpu.features: FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM PBE SSE3 PCLMULQDQ DTES64 MON DSCPL VMX SMX EST TM2 SSSE3 CX16 TPR PDCM SSE4.1 SSE4.2 x2APIC POPCNT AES PCID XSAVE OSXSAVE TSCTMR AVX1.0 RDRAND F16C

$ gnuradio-companion
-bash: gnuradio-companion: command not found

[michaelld (Michael Dickens)]

@lqfmickey: Interesting; can you do the following:

sudo port clean gnuradio-devel
sudo port -d configure gnuradio-devel > ~/Desktop/gr-conf-out.txt 2>&1
bzip2 ~/Desktop/gr-conf-out.txt

and then attach the compressed file to this ticket? I'm curious what it says it being built/installed and what not; and, why.

[michaelld (Michael Dickens)]

OK; so this issue happens with folks who's host computer CPU has AVX1.0. That is for certain. Next up is why clang34 does not always do the trick. Can folks do the following and attach the output:

sudo port -d rev-upgrade > ~/Desktop/mp-ru-out.txt 2>&1
bzip2 ~/Desktop/mp-ru-out.txt

Feel free to rename the output file as needed for attaching.

[michaelld (Michael Dickens)]

Thanks for both files, @lqfmickey. I'm moving on to whatever else I can think of with respect to the runtime SIGSEGV issue; I had thought it was using different C++ runtimes for different builds, but that does not seem to be the case at least for @lqfmickey. Maybe others will respond to my request for the "rev-upgrade" text output?

@lqfmickey: gnuradio-companion isn't being built because CMake is not finding py*lxml. The debug output says that port thinks lxml is installed. What does "port installed py27-lxml" return for you? Also if you do the following, what does it return:

/opt/local/bin/python2.7 -c "import lxml.etree; print lxml.etree.LXML_VERSION"
port contents py27-lxml | sed -e 1d -e "s@.*packages/\([^/]*\)/.*@\1@g" | sort -u

[lqfmickey@…]

Thank you for your help, Michael! Here are the results:

$ port installed py27-lxml
The following ports are currently installed:
  py27-lxml @3.2.4_0 (active)

$ /opt/local/bin/python2.7 -c "import lxml.etree; print lxml.etree.LXML_VERSION"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: dlopen(/Library/Python/2.7/site-packages/lxml-3.2.4-py2.7-macosx-10.9-intel.egg/lxml/etree.so, 2): Symbol not found: _lzma_auto_decoder
  Referenced from: /Library/Python/2.7/site-packages/lxml-3.2.4-py2.7-macosx-10.9-intel.egg/lxml/etree.so
  Expected in: flat namespace
 in /Library/Python/2.7/site-packages/lxml-3.2.4-py2.7-macosx-10.9-intel.egg/lxml/etree.so

$ port contents py27-lxml | sed -e 1d -e "s@.*packages/\([^/]*\)/.*@\1@g" | sort -u
lxml
lxml-3.2.4-py2.7.egg-info

[michaelld (Michael Dickens)]

@lqfmickey: Your issue is that you have lxml installed in /Library/Python already. I think your best solution is to remove that package:

cd /Library/Python/2.7/site-packages
sudo rm -rf lxml*

and then try with gnuradio again:

sudo port uninstall gnuradio-devel
sudo port selfupdate
sudo port install gnuradio-devel

and this time GRC should be available. If not, try the

/opt/local/bin/python2.7 -c "import lxml.etree; print lxml.etree.LXML_VERSION"

again to see if there is some other location where lxml is being found.

[lqfmickey@…]

@michael: Problem solved! Everything works well. Thank you very much!

[michaelld (Michael Dickens)]

@lqfmickey: Great! One down, plenty to go .... :)

[michaelld (Michael Dickens)]

@konstanty and @scott: Any chance you can do the rev-upgrade request from above?

[jboone (Jared Boone)]

Replying to michaelld@…:

OK; so this issue happens with folks who's host computer CPU has AVX1.0. That is for certain. Next up is why clang34 does not always do the trick. Can folks do the following and attach the output:

sudo port -d rev-upgrade > ~/Desktop/mp-ru-out.txt 2>&1
bzip2 ~/Desktop/mp-ru-out.txt

Feel free to rename the output file as needed for attaching.

Attached. Hopefully, it'll help.

[jboone (Jared Boone)]

Replying to jboone@…:

Replying to michaelld@…:

OK; so this issue happens with folks who's host computer CPU has AVX1.0. That is for certain. Next up is why clang34 does not always do the trick. Can folks do the following and attach the output:

sudo port -d rev-upgrade > ~/Desktop/mp-ru-out.txt 2>&1
bzip2 ~/Desktop/mp-ru-out.txt

Feel free to rename the output file as needed for attaching.

Attached. Hopefully, it'll help.

But wait... I uninstalled gnuradio-companion for some reason. So maybe that latest attachment wasn't useful. I'll get back to you.

[michaelld (Michael Dickens)]

Thanks, @jboone. It is not necessary to have gnuradio installed. That file is just like the rest I've seen, which means what I had hoped was the issue is not. So, back to thinking of creative things to try.

For those folks having issues, I always recommend doing the following; sometimes it works:

sudo port clean gnuradio gnuradio-devel
sudo port -f -p uninstall gnuradio gnuradio-devel
sudo port selfupdate
sudo port install gnuradio-devel configure.compiler=macports-clang-3.4

and, if that all works, then try:

/opt/local/share/gnuradio/examples/audio/dial_tone.py

and if that works, then see if gnuradio-companion both executes as well as can run a flow-graph.

[jboone (Jared Boone)]

Replying to michaelld@…:

For those folks having issues, I always recommend doing the following; sometimes it works:

sudo port clean gnuradio gnuradio-devel
sudo port -f -p uninstall gnuradio gnuradio-devel
sudo port selfupdate
sudo port install gnuradio-devel configure.compiler=macports-clang-3.4

and, if that all works, then try:

/opt/local/share/gnuradio/examples/audio/dial_tone.py

and if that works, then see if gnuradio-companion both executes as well as can run a flow-graph.

I tried these things, using SVN MacPorts and doing an "svn update" just before, to r113550. It built, but I got the cxx_stdlib stuff again:

--->  Scanning binaries for linking errors: 55.1%
Warning: /opt/local/bin/i686-apple-darwin13-llvm-cpp-4.2 uses /usr/lib/libstdc++.6.dylib as C++ standard library although macports::cxx_stdlib is set to libc++.
--->  Scanning binaries for linking errors: 55.2%
Warning: /opt/local/bin/i686-apple-darwin13-llvm-g++-4.2 uses /usr/lib/libstdc++.6.dylib as C++ standard library although macports::cxx_stdlib is set to libc++.
--->  Scanning binaries for linking errors: 55.2%
Warning: /opt/local/bin/i686-apple-darwin13-llvm-gcc-4.2 uses /usr/lib/libstdc++.6.dylib as C++ standard library although macports::cxx_stdlib is set to libc++.
--->  Scanning binaries for linking errors: 55.5%
Warning: /opt/local/bin/llvm-gcov-4.2 uses /usr/lib/libstdc++.6.dylib as C++ standard library although macports::cxx_stdlib is set to libc++.
--->  Scanning binaries for linking errors: 55.7%
Warning: /opt/local/libexec/llvm-gcc42/gcc/i686-apple-darwin13/4.2.1/cc1 uses /usr/lib/libstdc++.6.dylib as C++ standard library although macports::cxx_stdlib is set to libc++.
--->  Scanning binaries for linking errors: 55.8%
Warning: /opt/local/libexec/llvm-gcc42/gcc/i686-apple-darwin13/4.2.1/cc1obj uses /usr/lib/libstdc++.6.dylib as C++ standard library although macports::cxx_stdlib is set to libc++.
--->  Scanning binaries for linking errors: 55.8%
Warning: /opt/local/libexec/llvm-gcc42/gcc/i686-apple-darwin13/4.2.1/cc1objplus uses /usr/lib/libstdc++.6.dylib as C++ standard library although macports::cxx_stdlib is set to libc++.
--->  Scanning binaries for linking errors: 55.9%
Warning: /opt/local/libexec/llvm-gcc42/gcc/i686-apple-darwin13/4.2.1/cc1plus uses /usr/lib/libstdc++.6.dylib as C++ standard library although macports::cxx_stdlib is set to libc++.
--->  Scanning binaries for linking errors: 56.0%
Warning: /opt/local/libexec/llvm-gcc42/gcc/i686-apple-darwin13/4.2.1/collect2 uses /usr/lib/libstdc++.6.dylib as C++ standard library although macports::cxx_stdlib is set to libc++.
--->  Scanning binaries for linking errors: 56.1%
Warning: /opt/local/libexec/llvm-gcc42/gcc/i686-apple-darwin13/4.2.1/libllvmgcc.dylib uses /usr/lib/libstdc++.6.dylib as C++ standard library although macports::cxx_stdlib is set to libc++.
--->  Scanning binaries for linking errors: 100.0%

When I ran the example you suggested, I got a "Bus error: 10" and a dialog to report a problem for Python. Among the details it offered:

Crashed Thread:  4

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x000000010a6fbd60

VM Regions Near 0x10a6fbd60:
    STACK GUARD            000000010a67b000-000000010a67c000 [    4K] ---/rwx SM=NUL  stack guard for thread 4
--> Stack                  000000010a67c000-000000010a6fe000 [  520K] rw-/rwx SM=COW  thread 4
    STACK GUARD            000000010a6fe000-000000010a6ff000 [    4K] ---/rwx SM=NUL  stack guard for thread 5

Thread 0:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	0x00007fff86ca4e7a __bsdthread_create + 10
1   libsystem_pthread.dylib       	0x00007fff879a3dcb pthread_create + 201
2   libboost_thread-mt.dylib      	0x000000010501c5ec boost::thread::start_thread_noexcept() + 124
3   libgnuradio-runtime.3.7.3git.dylib	0x0000000104e0a4a0 boost::thread::start_thread() + 16
4   libgnuradio-runtime.3.7.3git.dylib	0x0000000104e0a428 boost::thread::thread<boost::function0<void> >(boost::function0<void>, boost::disable_if_c<boost::thread_detail::is_convertible<boost::function0<void>&, boost::detail::thread_move_t<boost::function0<void> > >::value, boost::thread::dummy*>::type) + 100
5   libgnuradio-runtime.3.7.3git.dylib	0x0000000104e0a088 gr::thread::thread_group::create_thread(boost::function0<void> const&) + 58
6   libgnuradio-runtime.3.7.3git.dylib	0x0000000104e49369 gr::scheduler_tpb::scheduler_tpb(boost::shared_ptr<gr::flat_flowgraph>, int) + 1007
7   libgnuradio-runtime.3.7.3git.dylib	0x0000000104e48f12 gr::scheduler_tpb::make(boost::shared_ptr<gr::flat_flowgraph>, int) + 88
8   libgnuradio-runtime.3.7.3git.dylib	0x0000000104e55548 gr::make_scheduler(boost::shared_ptr<gr::flat_flowgraph>, int) + 264
9   libgnuradio-runtime.3.7.3git.dylib	0x0000000104e55290 gr::top_block_impl::start(int) + 440
10  libgnuradio-runtime.3.7.3git.dylib	0x0000000104e548fe gr::top_block::start(int) + 28
11  _runtime_swig.so              	0x0000000104beb030 top_block_start_unlocked(boost::shared_ptr<gr::top_block>, int) + 35
12  _runtime_swig.so              	0x0000000104c571b3 _wrap_top_block_start_unlocked(_object*, _object*, _object*) + 281
13  org.python.python             	0x000000010485d345 PyEval_EvalFrameEx + 16725
14  org.python.python             	0x0000000104859076 PyEval_EvalCodeEx + 1734
15  org.python.python             	0x000000010485ff36 fast_function + 294
16  org.python.python             	0x000000010485c28b PyEval_EvalFrameEx + 12443
17  org.python.python             	0x0000000104859076 PyEval_EvalCodeEx + 1734
18  org.python.python             	0x000000010485ff36 fast_function + 294
19  org.python.python             	0x000000010485c28b PyEval_EvalFrameEx + 12443
20  org.python.python             	0x0000000104859076 PyEval_EvalCodeEx + 1734
21  org.python.python             	0x000000010485ff36 fast_function + 294
22  org.python.python             	0x000000010485c28b PyEval_EvalFrameEx + 12443
23  org.python.python             	0x0000000104859076 PyEval_EvalCodeEx + 1734
24  org.python.python             	0x00000001048589a6 PyEval_EvalCode + 54
25  org.python.python             	0x0000000104880611 PyRun_FileExFlags + 161
26  org.python.python             	0x000000010488015e PyRun_SimpleFileExFlags + 718
27  org.python.python             	0x0000000104894002 Py_Main + 3314
28  libdyld.dylib                 	0x00007fff92afa5fd start + 1

Thread 1:
0   libsystem_kernel.dylib        	0x00007fff86ca5e6a __workq_kernreturn + 10
1   libsystem_pthread.dylib       	0x00007fff879a4f08 _pthread_wqthread + 330
2   libsystem_pthread.dylib       	0x00007fff879a7fb9 start_wqthread + 13

Thread 2:: Dispatch queue: com.apple.libdispatch-manager
0   libsystem_kernel.dylib        	0x00007fff86ca6662 kevent64 + 10
1   libdispatch.dylib             	0x00007fff8d29c43d _dispatch_mgr_invoke + 239
2   libdispatch.dylib             	0x00007fff8d29c152 _dispatch_mgr_thread + 52

Thread 3:
0   libsystem_kernel.dylib        	0x00007fff86ca5e6a __workq_kernreturn + 10
1   libsystem_pthread.dylib       	0x00007fff879a4f08 _pthread_wqthread + 330
2   libsystem_pthread.dylib       	0x00007fff879a7fb9 start_wqthread + 13

Thread 4 Crashed:
0   ???                           	0x000000010a6fbd60 0 + 4470062432

Thread 5:
0   ???                           	0x000000010a77ed60 0 + 4470599008

Thread 6:
0   libsystem_pthread.dylib       	0x00007fff879a7fbc thread_start + 0

Thread 4 crashed with X86 Thread State (64-bit):
  rax: 0x0000000000000002  rbx: 0x00007fcaed10e4e0  rcx: 0x0000000000000010  rdx: 0xffffffffffffffe0
  rdi: 0x00007fcaed10e4c0  rsi: 0x0000000000000000  rbp: 0x000000010a6fbb60  rsp: 0x000000010a6fbb68
   r8: 0x0000000000000100   r9: 0x000000010a67b000  r10: 0x0000000000000000  r11: 0x0000000000000246
  r12: 0x0000000000007c03  r13: 0x00007fcaed10efa0  r14: 0x000000010a6fbd70  r15: 0x000000010501c660
  rip: 0x000000010a6fbd60  rfl: 0x0000000000010202  cr2: 0x000000010a6fbd60
  
Logical CPU:     1
Error Code:      0x00000015
Trap Number:     14

[slarew]

Cc Me!

[michaelld (Michael Dickens)]

As of r113561, pretty much any compiler should work on 10.8 or 10.9 to build any version of gnuradio (legacy, release, devel, next). If your build is broken, please try:

sudo port clean gnuradio gnuradio-devel
sudo port -f -p uninstall gnuradio gnuradio-devel
sudo port selfupdate
sudo port install gnuradio-devel

and then see if the dial_tone works; see if gnuradio-companion works.

[jboone (Jared Boone)]

Replying to michaelld@…:

As of r113561, pretty much any compiler should work on 10.8 or 10.9 to build any version of gnuradio (legacy, release, devel, next). If your build is broken, please try:

Brilliant! Dial tone runs correctly, gnuradio-companion runs fine, and I can launch a graph from GRC that operates correctly. Many thanks!

[michaelld (Michael Dickens)]

@jboone: Thanks for the feedback; I'm glad it working; you're (all) welcome! I'm going to go ahead and close this ticket as fixed, finally. If it does not build for anyone with these same issues, please reopen. If it does not build with other issues, please create a new ticket.

[slarew]

Cc Me!