GNU Radio release 3.6.3 available for download

aris · January 8, 2013, 10:37pm

GNU Radio release 3.6.3 is available here:

http://gnuradio.org/releases/gnuradio/gnuradio-3.6.3.tar.gz http://gnuradio.org/releases/gnuradio/gnuradio-3.6.3rc0.tar.gz

Contributors this release:

Alick Z. [email protected]
Alexandru C. [email protected]
Ben H. [email protected]
Ben R. [email protected]
Brett L. Trotter [email protected]
Johnathan C. [email protected]
Josh B. [email protected]
Julien Olivain [email protected]
Martin B. [email protected]
Michael D. [email protected]
Nicholas C. [email protected]
Tim O’Shea [email protected]
Tim N. [email protected]
Tom R. [email protected]

Release 3.6.3 is a significant release, adding major new
capabilities and many bug fixes, while maintaining strict source
compatibility with user code already written for the 3.6 API.

Much of the code was the result of two events, the September 2012 GNU
Radio conference in Atlanta, GA, and the November 2012 GNU Radio
hackfest held at Ettus R. in Mountain View, CA. Additional work
(not discussed here) from these events has been incorporated into the
‘next’ branch of the code repository, and will become part of the 3.7
API release series.

New features include asynchronous message passing between blocks, new
blocks for interfacing with operating system networking stacks, the
ability to write new signal processing blocks in Python, enhanced file
source and sinks that can store metadata, flowgraph latency control,
improvements to documentation, and further conversion of existing code
into the 3.7 API organization (while leaving existing blocks in
place.)

Enjoy!

Johnathan C.
Corgan Labs

Detailed changelog:

Addition/upgrade of message passing infrastructure (Tim O’Shea, Tom
Rondeau, Johnathan C., Josh B.)

This introduces the ability to add and connect formally defined
asychronous message ports to signal processing blocks and
hierarchical blocks.  These message ports can be connected to pass
asynchronous data in the form of PMTs (polymorphic types) among
blocks in a flowgraph.  It is also possible to implement pure
message passing blocks that have no requirement for streaming
ports or work functions.

We've also introduced the concept of PDUs (Protocol Data Units) as
a convention for passing data+metadata using the new messaging
ports. A PDU is a PMT pair that combines a PMT dictionary of
metadata keys/values along with a PMT blob to hold a vector of
data in memory.

A few new general purpose blocks supporting these capabilties are
in gnuradio-core:

gr_message_debug
gr_message_strobe
gr_tagged_stream_to_pdu
gr_pdu_to_tagged_stream

Two new blocks for interfacing with networking stacks using the
new PDU semantics:

gr_socket_pdu
gr_tuntap_pdu

This new message passing capability and PDU convention is aimed at
providing the infrastructure to better support software radio
implementations using packet-oriented semantics, such as MAC-layer
processing.

Addition of new Python-based signal processing blocks (Josh B.)

This feature, originally introduced by Josh B. as part of
GrExtras, allows implementing signal processing blocks directly in
Python, and has now become a standard feature of GNU Radio.

Addition of gr-analog top-level component (Tom R.)

This implements the current gnuradio-core signal processing blocks
used for analog signal processing into their own top-level
component, gr-analog, and uses the new 3.7 API organization. The
original blocks in gnuradio-core will be removed on the 3.7 branch
prior to 3.7 release.

Addition of gr-blocks top-level component (Johnathan C.)

This implements a large portion of the gnuradio-core non-signal
processing blocks in the 3.7 API form.  The original blocks in
gnuradio-core will be removed on the 3.7 branch prior to 3.7
release.

Metadata file source and sink blocks (Tom R.)

Two new blocks implement enhanced file source and sink blocks that
incorporate metadata passed using the stream tags feature in GNU
Radio.  It is now possible to store things like frequency and
sample rate into capture files, or whatever key/value pairs you
tag onto data streams inside a flowgraph.

http://www.trondeau.com/home/2012/12/15/metadata-file-format.html

GNU Radio buffer latency control (Tim O’Shea, Tom R.)

For finer-grained control over latency inside a GNU Radio
flowgraph, it is now possible to adjust, on a per-block basis, the
maximum noutput_items that will be used to call a block work
function.  In addition, it is possible to set the maximum size an
output buffer can grow to before a work function is called.

New GNU Radio Companion (GRC) capabilities

Added optional flag to pad source and sink (Josh B.)
Added wildcard type to pad source and sink (Josh B.)
Added ability to reload XML for block (Tim O'Shea)
Added ability to automatically create hier_blocks from a flowgraph

(Tim
Newman)
Added ability to open custom GRC hier block definitions (Tim O’Shea)
Added new grcc command line GRC-to-Python utility (Tom R.)

New Documentation Updates (Tom R.)

We are introducing documentation into the Doxygen manual
describing features and capabilities of GNU Radio, above and
beyond just documenting the API functions.  Tom R. has
written about this here:

Some examples of commits where this has been done:

http://gnuradio.org/cgit/gnuradio.git/commit/?id=77ea309 (PMT type

usage)
gnuradio.git - GNU Radio (Message
passing interface)
gnuradio.git - GNU Radio (Metatdata
format)
gnuradio.git - GNU Radio (Max output
buffer control)

Other new features:

Allow file source to open new files while running (Brett L. Trotter)
Allow source blocks to return none/yield (Josh B.)
Improved capabilities of uhd_fft.grc example in gr-uhd (Ben H.)
Added parameter in qtgui sink's GRC block to set the update rate

(Julien Olivain)
Added source block hook in gr-uhd for issue stream cmd (Josh B.)
Added cmake package support for Ubuntu 12.10 (Nicholas C.)
Added gr::blocks::patterned_interleaver (Tim O’Shea)
Allow user to set Python path during cmake configuration (Tom
Rondeau)
Enabled serialize/deserialize for PMT vectors (Tom R.)
Added unsigned long long int support to the PMT sugar functions (Tom
Rondeau)
Allow using pmt_init_Xvector methods in python (Tom R.)

Bug fixes:

Numerous cmake related bug-fixes (Josh B., Johnathan C., Tom

Rondeau)
Overhaul of cmake include directory ordering (Michael D.)
Fixed parallel build failures in cmake (Tom R.)
Fixed segfaults due to old, no longer nedded SWIG workaround (Tom
Rondeau)
Fixed memory leak issue in arbitrary resampler blocks (Tom ROndeau)
Fixed use of default noise seed in channel model (Alick Z.)
Fixed scaling bug in QAM constellations (Ben R.)
Fixed installation of grc examples (Johnathan C.)
Fixed finding Qwt6 installed on OSX using MacPorts (Ben R.)
Fixed implicit assumption in skiphead (Josh B.)
Fixed include tag include usage throughout core (Josh B.)
Fixed incorrect private usage in gr_endian_swap (Josh B.)
Fixed segfault in gr-filter due to memory free bug (Josh B.)
Fixed UHD pmt tuple ref namespace issue (Josh B.)
Fixed gr_tag_debug to handle lacking srcid (Martin B.)
Fixed gr-analog for ‘sincos(f)’ on MacOSX (Michael D.)
Fixed gr-analog build issues on Windows (Nicholas C.)
Fixed qtgui time sink to take the bandwidth parameter to set x-axis
correctly (Tom R.)
Fixed float-in, complex-out fft block to use the right io sig (Tom
Rondeau)
Fixed Clang imcompatibility by removing ‘.version’ lines in ASM code
in
core (Tom R.)
Fixed file_meta_source/sink incompatibilities with MSVC (Nicholas
Corgan)
Fixed some unused parameter warnings (Alexandru C.)

jconley · January 9, 2013, 3:42pm

On Jan 8, 2013, at 4:35 PM, Johnathan C. [email protected]
wrote:

GNU Radio release 3.6.3 is available here:

For Mac OS X GNU Radio users: This morning (1/9) I updated the MacPorts’
install to this release (“gnuradio”) as well as the latest GIT master
(“gnuradio-devel”) and next (“gnuradio-next”).

NOTES:

With the latest changes to the CMake build files, as well as the
addition of scipy as a runtime requirement, I believe I’ve found all of
the dependencies within GNU Radio whether for building or runtime. GNU
Radio should be easy to install and use (for you) and maintain (for me)
within the MacPorts environment. If you have any issues when installing
via MacPorts please search for the issue <
Search – MacPorts >, and if you don’t find it then report
the issue in a ticket < https://trac.macports.org/newticket >; set the
owner as “[email protected]”.
Please do “port variants gnuradio” to understand your install options:
by default, GNU Radio is installed with only the basic dependencies,
which means no SWIG (Python interface), Wx, Qt, GRC, SDL, or the like.
I recommend installing via “sudo port install gnuradio +full”, but I
recognize that not everyone wants to wait around for hours while Qt4 is
installed; hence, I’m making none of these variants active by default.
By “popular request” this behavior is a change from the past, when
everything was installed by default.
For those trying “next”, I’ve added a variant for ctrlport as
EXPERIMENTAL – it does not work for me, but maybe it will for you.
This variant is not part of “+full”; you will have to specify it
explicitly.

Enjoy! - MLD

jconley · January 9, 2013, 5:03pm

On Jan 9, 2013, at 9:41 AM, Michael D. [email protected] wrote:

On Jan 8, 2013, at 4:35 PM, Johnathan C. [email protected] wrote:

GNU Radio release 3.6.3 is available here:

For Mac OS X GNU Radio users: This morning (1/9) I updated the MacPorts’ install
to this release (“gnuradio”) as well as the latest GIT master (“gnuradio-devel”)
and next (“gnuradio-next”).

I forgot to mention: MacPorts’ boost port is currently at 1.52 – the
latest release – which has bugs in the way it handles threads, does not
work with GNU Radio (and, it seems, many other projects), and hence has
been removed from the GNU Radio acceptable versions. The fix is already
in place for 1.53, but this release has not yet been made. Thus, in the
mean time you can manually reinstall 1.51, or activate any version of
boost from 1.35 to 1.51.

Follow these commands to manually reinstall 1.51:

cd ~/Desktop
mkdir tmp_boost
cd tmp_boost
svn co -r 98466
http://svn.macports.org/repository/macports/trunk/dports/devel/boost
cd boost
sudo port build

You can add variants after “build” if you want; just make sure that
those variants are also added after the “install” command below.
Assuming the build succeeds, then do:

ff=port installed boost | sed -e "1d" -e "s@(active)@@g"
sudo port -f deactivate $ff
sudo port install

and, remember to add any variants from “build” above after “install”.
You can clean up this install via:

cd Desktop
sudo rm -rf tmp_boost

Once this install or boost succeeds, you should be ready to go with
installing and/or using GNU Radio in MacPorts. If one of the GNU Radio
ports is already installed, it should now “just work” without having to
be reinstalled.

Remember to not upgrade boost until 1.53 is available via MacPorts. I
hope that Boost 1.53 will be released soon, to take care of this issue
(and, I’m sure, others). If you are using MacPorts and have questions
about this, feel free to ping me. - MLD

jconley · January 9, 2013, 10:34pm

On Wed, Jan 9, 2013 at 5:02 PM, Michael D. [email protected]
wrote:

latest release – which has bugs in the way it handles threads, does not
cd tmp_boost
sudo port -f deactivate $ff
ports is already installed, it should now “just work” without having to be
reinstalled.

Remember to not upgrade boost until 1.53 is available via MacPorts. I
hope that Boost 1.53 will be released soon, to take care of this issue
(and, I’m sure, others). If you are using MacPorts and have questions
about this, feel free to ping me. - MLD

Hi Michael,

Thanks for the detailed instructions.

I didn’t have macports installed so I started from scratch. I installed
macports, then boost 1.51 according to your instructions. Then I try to
install uhd before gnuradio:

sudo ports install uhd +libusb

and that installs boost 1.52

If you have any advice for what I should do before continuing with
gnuradio, please let me know.

Alex

jconley · January 10, 2013, 2:21am

On Jan 9, 2013, at 4:33 PM, Alexandru C. [email protected] wrote:

Thanks for the detailed instructions.

I didn’t have macports installed so I started from scratch. I installed
macports, then boost 1.51 according to your instructions. Then I try to install
uhd before gnuradio:

sudo ports install uhd +libusb

and that installs boost 1.52

If you have any advice for what I should do before continuing with gnuradio,
please let me know.

Hi Alexandru - You’re welcome! I’m glad to hear from OSX GNU Radio
users.

Chances are that boost 1.51 is still installed, but not active in
MacPorts. You can view all of the installed boost ports via:

port installed boost

to verify that it’s still around. If not, try re-doing my instructions
for installing boost 1.51. If it is around, you can try this to make
sure boost 1.51 is the active boost:

gg=port installed boost | grep 51 | sed -e "s@(active)@@g"
sudo port activate $gg

If Boost 1.51 is already active, the above will do nothing. If it is
not active, it should be made so, an boost 1.52 deactivated (first).
Both GNU Radio and UHD work with Boost 1.51, so all you should have to
do is (re)activate the older Boost.

You can verify which version of Boost is active via:

port installed boost | grep active

Hope this helps! - MLD

jconley · January 10, 2013, 9:36pm

On Thu, Jan 10, 2013 at 2:20 AM, Michael D. [email protected]
wrote:

If Boost 1.51 is already active, the above will do nothing. If it is not
active, it should be made so, an boost 1.52 deactivated (first). Both GNU Radio
and UHD work with Boost 1.51, so all you should have to do is (re)activate the
older Boost.

You can verify which version of Boost is active via:

port installed boost | grep active

Hi Mike,

Thanks for your help. As it turns out, I simply forgot to run the last
step that actually installs boost 1.51 after building it - that
explains why boost 1.52 got installed with uhd. I have now rebuilt
1.51, deactivated 1.52 and installed 1.51. Everything is ok now and I
installed gnuradio without problems.

I used: “sudo port install gnuradio +orc +uhd”
During configuration I saw the message:

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.

Do you have any experience whether this can be a real performance
issue and what I can do to use gcc instead of clang?

Alex

jconley · January 10, 2013, 9:46pm

On Jan 10, 2013, at 3:35 PM, Alexandru C. [email protected] wrote:

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.

Do you have any experience whether this can be a real performance
issue and what I can do to use gcc instead of clang?

You’re welcome! I’m glad you’ve got GNU Radio installed on Mac OS X via
MacPorts.

I’ll leave the performance question up to those who wrote Volk. I’m
guessing that if Volk keys on GCC for optimizations, then using clang
will disable most optimizations. But, I’m no expert here.

You can select a compiler suite by appending to the usual “port”
commands “configure.compiler=XXX”, where XXX is one of:

gcc-3.3 gcc-4.0 gcc-4.2 llvm-gcc-4.2 clang apple-gcc-4.0 apple-gcc-4.2
macports-gcc-4.1 macports-gcc-4.2macports-gcc-4.3 macports-gcc-4.4
macports-gcc-4.5 macports-gcc-4.6 macports-gcc-4.7 macports-gcc-4.8
macports-clang-2.9 macports-clang-3.0 macports-clang-3.1
macports-clang-3.2

Note that “clang” is Apple’s installed clang, no matter the version
(could be 2.1, 3.1, 4.1; maybe others). If you’re running on Mac OS X
10.7 or 10.8, I’d recommend using the following:

sudo port install gnuradio +orc +uhd configure.compiler=llvm-gcc-4.2

to get Volk using a compatible GCC & thence the optimizations therein.
You can find out a little (but, not much) more about this topic at <
MacPorts Guide > and then scroll
down to or search for “configure.compiler”.

Hope this helps! - MLD

jconley · January 11, 2013, 12:11am

On Thu, Jan 10, 2013 at 9:44 PM, Michael D. [email protected]
wrote:

Thanks for the tip - I will try to rebuild using gcc later and see
what difference it makes. For now I am happy that after installing
gnuradio, I could install the rtl-sdr and gr-osmosdr packages, and
since I already had Qt 4.8 installed I could also build gqrx without
major issues.

Concerning performance, I do see an “Using Volk machine: generic_orc”
message when I start gqrx; however, running an FM stereo receiver with
an rtlsdr dongle at 2 Msps, 4096 point fft at 30 fps with averaging
enabled consumes about 50% cpu on a dual core imac from early 2009.
I’m quite satisfied with that.

Alex

jconley · January 16, 2013, 3:16pm

Thank you!!!

-brian

jconley · January 17, 2013, 9:20pm

Mike,

maybe even the scan thing I noted above. See problem loading the dylib below:

ImportError:
dlopen(/opt/local/lib/python2.7/site-packages/osmosdr/_osmosdr_swig.so, 2):
Library not loaded: libgnuradio-osmosdr.0.dylib

Referenced from:
/opt/local/lib/python2.7/site-packages/osmosdr/_osmosdr_swig.so

Reason: image not found

Seems like I am missing one final detail that glues the proper loading of the
dynamic libraries?

I’m wondering where “libgnuradio-osmosdr.0.dylib” is located. Usually this
would be installed into ${prefix}/lib (so, /opt/local/lib in your case).

Yes it was in /opt/local/lib. Don’t know why the system can’t find it.

If I cd to /opt/local/lib and then run gnu radio-companion, works great,
if I am not cd to that directory it fails every time.

I also tried adding /opt/local/lib to the PATH but that did not help.

At least I can run successfully now, even though have to cd to that
directory.

I think Alex might have also said something similar not that I say this,
I think he said he had to copy libs to the directory of his executable.

If you think of any potential solution, let me know. Otherwise I guess
I will play with things for a while with this work around, and revisit
trying to figure out why later.

Thanks for your suggestions and help,
mlk

jconley · January 17, 2013, 9:41pm

On 16/01/13 09:02 PM, Michael L Kornegay wrote:

Yes it was in /opt/local/lib. Don’t know why the system can’t find it.

If I cd to /opt/local/lib and then run gnu radio-companion, works great, if I am
not cd to that directory it fails every time.

I also tried adding /opt/local/lib to the PATH but that did not help.
PATH is used for locating executable programs, not libraries.

UNIX-like systems often use LD_LIBRARY_PATH to extend the
system-configured paths for libraries.

Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page

–
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

jconley · January 17, 2013, 10:08pm

On 01/16/2013 09:37 PM, Marcus D. Leech wrote:

I’m wondering where “libgnuradio-osmosdr.0.dylib” is located. Usually this
would be installed into ${prefix}/lib (so, /opt/local/lib in your case).

if you come from a windows background, PATH is used for dlls and
executables. However, for OSX, you will want to set DYLD_LIBRARY_PATH to
contain your dylibs

-josh

jconley · January 18, 2013, 5:49am

Mike - What does “otool -L
/opt/local/lib/python2.7/site-packages/osmosdr/_osmosdr_swig.so” return?
If it does not contain “/opt/local/lib/libgnuradio-osmosdr.0.dylib”,
then there is a library linking issue. If it does, then I’ll try
installing it myself to see what’s going on.

On Jan 16, 2013, at 11:05 PM, Josh B. [email protected] wrote:

if you come from a windows background, PATH is used for dlls and
executables. However, for OSX, you will want to set DYLD_LIBRARY_PATH to
contain your dylibs

Even better on OSX is that you want to make sure all of the link-to
libraries are correctly linked-to. This is what MacPorts’ “rev-upgrade”
phase does: verifies the self-integrity of the MacPorts-installed
libraries and binaries. In this way, when using MacPorts, one does not
need to set any DYLD_* stuff since everything is supposed to “just
work”.

For the purposes of “day to day” environment settings, I -highly-
recommend against using DYLD_LIBRARY_PATH or any of the DYLD_* variables
since that can really screw with the way things are meant to work. On
OSX, the library internally contains the other libraries upon which it
depends, with a full or relative path. So, for example, if there is a
conflict between libiconv (/usr/lib/libiconv* and
/opt/local/lib/libiconv*), if DYLD_LIBRARY_PATH is set to have
/opt/local/lib before /usr/lib, then that version of libiconv will be
“favored” (not guaranteed) over the other version. Which, if the 2
versions are not ABI compatible, has the potential to wreak havoc since
you as the user will often have no idea that they both exist, and thus
no idea why your program won’t run.

So, setting DYLD_LIBRARY_PATH can be useful when testing a project after
it is built but before it is installed – GNU Radio’s test script uses
this, both with CMake as well as prior with GNU Autotools. It’s a
wonderful short-term way to check out what you just compiled for issues,
assuming you can set it correctly to find your new libraries before the
old ones (e.g., if they were already installed).

MLD

jconley · January 22, 2013, 5:18am

Michael D. [email protected] writes:

WARNING: GNU Radio’s VOLK component (which handles vector optimized

to get Volk using a compatible GCC & thence the optimizations therein. You can
find out a little (but, not much) more about this topic at <
MacPorts Guide > and then scroll down to or
search for “configure.compiler”.

Hope this helps! - MLD

Hi, I tried to compile gnuradio 3.6.3 on MacPorts with the following
command:

sudo port install gnuradio +docs +grc +orc +python27 +qtgui +sdl +swig
+uhd +wxgui configure.compiler=macports-gcc-4.7

GNU Radio was installed successfully on my quad-core Core i7, but when I
execute GNU Radio Companion signal flow, I see the following messages:

_____ Message _____
Mac OS; Clang version 4.1 ((tags/Apple/clang-421.11.66)); Boost_105100;
UHD_003.005.000-0-unknown

Using Volk machine: generic_orc
gr-osmosdr supported device types: file fcd rtl rtl_tcp uhd
Using device #0 Compro VMU6xx SN: 0020
Found Elonics E4000 tuner
Exact sample rate is: 2000000.052982 Hz

gr_fir_ccf: using SSE
gr_fir_fff: using SSE
gr_fir_fcc: using SSE

Done
_____ Message _____

How can I make gnuradio and volk be optimzed for Core i7? generic_orc
seems not best optimized for core i7.

Thanks in advace!

Sincerely,

Albert

jconley · January 18, 2013, 5:29pm

ImportError:
dlopen(/opt/local/lib/python2.7/site-packages/osmosdr/_osmosdr_swig.so, 2):
Library not loaded: libgnuradio-osmosdr.0.dylib
Referenced from: /opt/local/lib/python2.7/site-packages/osmosdr/_osmosdr_swig.so
Reason: image not found

Seems like I am missing one final detail that glues the proper loading of the
dynamic libraries?

To follow up: I installed rtl-sdr using MacPorts, cloned gr-osmosdr and
did the usual build. After installing (into ${PREFIX}=/usr/local, of
course, to keep it in its own install space away from MacPorts), I
checked “otool -L
${PREFIX}/lib/python2.7/site-packages/osmosdr/_osmosdr_swig.so” and the
reference to “libgnuradio-osmosdr” is not correct; it reads
“libgnuradio-osmosdr.0.dylib” and should read
“${PREFIX}/lib/libgnuradio-osmosdr.0.dylib”. So, I checked “otool -L
${PREFIX}/lib/libgnuradio-osmosdr.0.dylib”, and it’s self-id [1] is not
correct; it reads “libgnuradio-osmosdr.0.dylib” and should be
“${PREFIX}/lib/libgnuradio-osmosdr.0.dylib”.

Now, when I check the version of this library from the top build
directory of osmosdr (call this ${OSMOSDR_BUILD_DIR}, “otool -L
lib/libgnuradio-osmosdr.dylib”, I get back the self-id of
“${OSMOSDR_BUILD_DIR}/lib/libgnuradio-osmosdr.0.dylib” – which is
correct. So, CMake when it is installing this library is not getting
its self-id correct, which in turn is messing up this library’s
reference in the SWIG library.

I looked at “gr-osmosdr/lib/CMakeLists.txt”, and nothing sticks out to
me as being really wrong. Maybe someone else with more time than me can
figure this one out? - MLD

ps> To rectify this issue, post install, you can always do the following
[with ${PREFIX} substituted correctly; you might need to “sudo” these,
depending on how you installed them in the first place]:

{{{
install_name_tool -change libgnuradio-osmosdr.0.dylib
${PREFIX}/lib/libgnuradio-osmosdr.0.dylib
${PREFIX}/lib/python2.7/site-packages/osmosdr/_osmosdr_swig.so
install_name_tool -id ${PREFIX}/lib/libgnuradio-osmosdr.0.dylib
${PREFIX}/lib/libgnuradio-osmosdr.0.dylib
}}}

[1] In Mac OS X, a library’s “self-id” is how it refers to itself,
generally including the full path; it can be set via
"/usr/bin/install_name_tool -id <NEW_ID> ". So, for example,
gnuradio-core’s self-id for a given ${PREFIX} will be something like
“${PREFIX}/lib/libgnuradio-core.dylib”. The self-id is used only when
the library is being used for linking purposes; it is otherwise ignored
by the DYLD subsystem.

jconley · January 22, 2013, 1:18pm

On Jan 21, 2013, at 11:17 PM, Albert Chun-Chieh H.
[email protected] wrote:

How can I make gnuradio and volk be optimzed for Core i7? generic_orc seems not
best optimized for core i7.

Hi Albert - I’m glad to hear of your general success in using MacPorts
for GNU Radio. For your particular question, I’ll let the VOLK folks
address the broad question regarding runtime selection of VOLK kernels /
machines. From my perspective, I’d like to know which kernels /
machines were detected at configuration time. You can get this info
independent of the install via:

{{{
sudo port -d configure gnuradio +docs +grc +orc +python27 +qtgui +sdl
+swig +uhd +wxgui configure.compiler=macports-gcc-4.7
}}}

and watch the output. Somewhere part way through, you’ll see a list
like this one (which is for my “old” laptop’s Intel Core 2 Duo (when
using the above command, btw):

{{{
– CPU width is 64 bits, Overruled arch 32
– Available architectures:
generic;64;3dnow;abm;popcount;mmx;sse;sse2;orc;norc;sse3;ssse3;sse4_a;sse4_1;sse4_2;avx
– Available machines:
generic_orc;sse2_64_mmx_orc;sse3_64_orc;ssse3_64_orc;sse4_a_64_orc;sse4_1_64_orc;sse4_2_64_orc;avx_64_mmx_orc
}}}

If you see these options, then there’s probably a way to select kernels
/ machines are runtime; but, as I said, I’ll leave that question up to
the VOLK developers. - MLD

jconley · January 23, 2013, 4:29am

Michael D. [email protected] writes:

On Jan 21, 2013, at 11:17 PM, Albert Chun-Chieh H. [email protected]
wrote:

How can I make gnuradio and volk be optimzed for Core i7? generic_orc seems not
best optimized for core i7.

Hi Albert - I’m glad to hear of your general success in using MacPorts
for GNU Radio. For your particular question, I’ll let the VOLK folks
address the broad question regarding runtime selection of VOLK kernels
/ machines. From my perspective, I’d like to know which kernels /
machines were detected at configuration time. You can get this info
independent of the install via:

Hi, Michael, I’m thankful for what you’ve done to Mac users. Before this
port, building GNU Radio was really distressing and normally I just gave
up after several failed builds and use GNU Radio in Linux.

Well, I tried to do a clean install MacPorts after this post. This time,
after MacPorts is installed, gcc 4.7 was installed first and used as
default compiler. Then I install every packages that gnuradio depends
with gcc 4.7. When I try to use gcc 4.7 to compile gnuradio with the
following command:

sudo port install gnuradio +docs +grc +orc +python27 +qtgui +sdl +swig
+uhd +wxgui configure.compiler=macports-gcc-4.7

The build was failed. And then I tried gcc 4.5 and it failed. Only when
I use llvm-gcc-4.2 would give me a successful build. When I run
gnuradio-companion, I got this message:

Mac OS; GNU C++ version 4.7.2; Boost_105200; UHD_003.005.000-0-unknown

Using Volk machine: sse4_1_64_orc
gr-osmosdr supported device types: file fcd rtl rtl_tcp uhd
Using device #0 Compro VMU6xx SN: 0020
Found Elonics E4000 tuner
Exact sample rate is: 2000000.052982 Hz

gr_fir_ccf: using SSE
gr_fir_fff: using SSE
gr_fir_fcc: using SSE

– Available machines:
generic_orc;sse2_64_mmx_orc;sse3_64_orc;ssse3_64_orc;sse4_a_64_orc;sse4_1_64_orc;sse4_2_64_orc;avx_64_mmx_orc
}}}

If you see these options, then there’s probably a way to select
kernels / machines are runtime; but, as I said, I’ll leave that
question up to the VOLK developers. - MLD

If I run the following command:
sudo port -d configure gnuradio +docs +grc +orc +python27 +qtgui +sdl
+swig +uhd +wxgui configure.compiler=macports-gcc-4.7

The messages for VOLK part is:

– CPU width is 64 bits, Overruled arch 32
– Available architectures:
generic;64;3dnow;abm;popcount;mmx;sse;sse2;orc;norc;sse3;ssse3;sse4_a;sse4_1;sse4_2;avx
– Available machines:
generic_orc;sse2_64_mmx_orc;sse3_64_orc;ssse3_64_orc;sse4_a_64_orc;sse4_1_64_orc;sse4_2_64_orc;avx_64_mmx_orc

For the command:
sudo port -d configure gnuradio +docs +grc +orc +python27 +qtgui +sdl
+swig +uhd +wxgui configure.compiler=macports-gcc-4.7

– 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_mmx_orc;sse3_64_orc;ssse3_64_orc;sse4_1_64_orc

The difference seems to be AVX, and my configuration is listed below:
CPU: Quad-core Core i7, Ivy bridge architecture
OS: MacOSX 10.8.2
MacPorts version: 2.1.2 with latest sync on January 22
gcc version 4.7.2 (MacPorts gcc47 4.7.2_2)
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build
2336.11.00)

Thanks in advance.

Albert

jconley · January 23, 2013, 3:52pm

On Tue, Jan 22, 2013 at 10:27 PM, Albert Chun-Chieh H. <
[email protected]> wrote:

– CPU width is 64 bits, Overruled arch 32
– Available architectures:

generic;64;3dnow;abm;popcount;mmx;sse;sse2;orc;norc;sse3;ssse3;sse4_a;sse4_1;sse4_2;avx

– Available machines:

generic_orc;sse2_64_mmx_orc;sse3_64_orc;ssse3_64_orc;sse4_a_64_orc;sse4_1_64_orc;sse4_2_64_orc;avx_64_mmx_orc

For the command:
sudo port -d configure gnuradio +docs +grc +orc +python27 +qtgui +sdl
+swig +uhd +wxgui configure.compiler=macports-gcc-4.7

Albert,
This is the same command as above, or am I missing something?

The difference seems to be AVX, and my configuration is listed below:
CPU: Quad-core Core i7, Ivy bridge architecture
OS: MacOSX 10.8.2
MacPorts version: 2.1.2 with latest sync on January 22
gcc version 4.7.2 (MacPorts gcc47 4.7.2_2)
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)

Thanks in advance.

Albert

What if you configure without ORC?

Also, run volk_profile after you’ve built GNU Radio. It will test all of
the kernels and create a $HOME/.volk/volk_config file. If you look in
that
file, it will tell you what architectures are to be used for each
kernel.

Tom

jconley · January 23, 2013, 4:28pm

Hi Albert -

On Jan 22, 2013, at 10:27 PM, Albert Chun-Chieh H.
[email protected] wrote:

I’m thankful for what you’ve done to Mac users. Before this
port, building GNU Radio was really distressing and normally I just gave
up after several failed builds and use GNU Radio in Linux.

You’re welcome; I’m thankful too, since I do use GNU Radio for a few
projects off and on, and I like fixing the bugs and getting others’ bug
fixes in & thus keeping my install up to date. The new MacPorts
installs make that really simple, and seem to work for most users in
most cases. It’s also nice to have the time to keep my favorite ports
up to date, and maybe even add in a few new ones of relevance – I’m
thinking since rtl-sdr is part of MacPorts, I could maybe add in
gr-osmosdr too since it seems to be of some use to folks.

Well, I tried to do a clean install MacPorts after this post. This time,
after MacPorts is installed, gcc 4.7 was installed first and used as
default compiler. Then I install every packages that gnuradio depends
with gcc 4.7. When I try to use gcc 4.7 to compile gnuradio with the
following command:

sudo port install gnuradio +docs +grc +orc +python27 +qtgui +sdl +swig
+uhd +wxgui configure.compiler=macports-gcc-4.7

The build was failed. And then I tried gcc 4.5 and it failed.

Off list, can you send me the logfile from each failed build? I’ll try
it local to my computer, too, with gdd 4.7 (since that’s what I have
installed already and hence I can check this quickly) to see if I can
replicate it. Better to fix these bugs than let them persist when
reasonably possible!

Only when
I use llvm-gcc-4.2 would give me a successful build. When I run
gnuradio-companion, I got this message:

Using Volk machine: sse4_1_64_orc

Well, I’m glad one of the compilers worked! I don’t know much about
VOLK, but if it’s using SSE4 then that’s probably pretty fast and
efficient.