Status of GNU Radio with OSX 10.9

GNU Radio
1

Earlier today I pushed r113561 to MacPorts <
Changeset 113561 – MacPorts > which should allow pretty
much any compiler should work on 10.8 or 10.9 (and, likely, any other
OSX version) 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.
Compared with previous fixes, this one seems to work across the board.
So please give this change a try if you’re using GNU Radio on OSX via
MacPorts. Enjoy! - MLD

ps> The issue, as has been the case before, comes down the compiling
VOLK. This time, the problem is that Apple’s clang is some version of
3.3, which has issues with the cvtpi32_ps intrinsic on ACX. Clang 3.4
has the fixes for this intrinsic. So … long story short is that in
MacPorts only, I patch volk/lib/CMakeLists.txt to test for not just
xgetbv but also for cvtpi32_ps. I’m not sure it is important to include
this patch within GNU Radio proper, but it does specify “if (APPLE)” to
it could be done.

2

Nella citazione in data Wed Nov 20 00:50:52 2013, Michael D. ha
scritto:

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

Hi folks, can you give some good news about the building from source of
the gnuradio tarball ? As I previously said, i need to work with
gnuradio 3.6.5.1 and above…

Kind Regards,

        Arturo
3

Hi Arturo - GNU Radio 3.6.5.1 should now work within MacPorts; I’ve
tested on 10.8 and 10.9, but the fixes should be backward compatible to
at least 10.6, maybe 10.5. All of the GNU Radio ports should work right
now within MacPorts. If you want to build these from source outside
MacPorts, I’d advise to pretty much follow what the Portfile does
including needed patches. For example, to get SWIG working on 10.9 you
have to copy the whole swig/std directory to a place where SWIG files
will be looked for, then patch the correct files in the copy. Hope this
helps! - MLD

4

I think you should be able to have GNU Radio installed into /opt/local
but then you create an OOT module which installs into /usr/local . I
used to do this “way back in the day”; I would assume it still works.
Maybe you can send me off-list more info on what you’re trying to do and
I can point you in the right directions?

I think you could probably copy the files from
/opt/local/lib/python2.7/site-packages into
/usr/local/lib/python2.7/site-packages and they would probably work
about right. No guarantees though, since some libraries might be linked
against other libraries already in /opt/local somewhere. But, it’s
worth a try IMHO … - MLD

5

Nella citazione in data Mon Dec 2 19:42:56 2013, Michael D. ha
scritto:

Hi Arturo - GNU Radio 3.6.5.1 should now work within MacPorts; I’ve tested on
10.8 and 10.9, but the fixes should be backward compatible to at least 10.6, maybe
10.5. All of the GNU Radio ports should work right now within MacPorts. If you
want to build these from source outside MacPorts, I’d advise to pretty much follow
what the Portfile does including needed patches. For example, to get SWIG working
on 10.9 you have to copy the whole swig/std directory to a place where SWIG files
will be looked for, then patch the correct files in the copy. Hope this helps! -
MLD

On Dec 2, 2013, at 1:30 PM, Arturo R. [email protected] wrote:

Hi folks, can you give some good news about the building from source of the
gnuradio tarball ? As I previously said, i need to work with gnuradio 3.6.5.1 and
above…

Thank you again Michael, I was wondering If I could redirect the
installation path of the port to

/usr/local/lib/python2.7/site-packages

instead of

/opt/local/lib/python2.7/site-packages

would this be possible or not ? Basically, it’s what I really need to
install custom gnuradio modules without messing with the “/opt/local”
root path. This will totally cancel my need to perform a building from
tarball.

Regards again,

             Arturo
6

Nella citazione in data Mon Dec 2 20:03:22 2013, Michael D. ha
scritto:

instead of

/opt/local/lib/python2.7/site-packages

would this be possible or not ? Basically, it’s what I really need to install
custom gnuradio modules without messing with the “/opt/local” root path. This will
totally cancel my need to perform a building from tarball.

mmm I see…ok let’s do it this way. Let’s say that i untar the
3.6.5.1 tarball and write a script that patches all the needed files
before running the usual steps of configuration.

If I have understood well what I have to do I need to use all the 8
diff files you uploaded on the macports server, join them and apply the
result to the extracted tarball directory. I can try that with

patch --dry-run

to find if the patching is properly perfromed and the files are not
affected by patching. Now i have to figure out which are the right diff
files to patch the legacy version and the new version since I’m
noticing that the source path structure is different in the new
tarball. Do I have to use all of them or not ? Can i write just one
single diff file to apply before building from source as usual ? I was
thinlking thah once the work is finished i could post it on the mailing
list so it’d be available for everyone…let me know if you like the
idea.

Regards, Arturo

7

Hi Arturo - You don’t need all 8 diff files. If you read through the
Portfile for GNU Radio, you’ll find that you need just 5 of those
patches to build 3.6.5.1 on 10.9; if you want to build on 10.8, you need
just 3.

Needed for 10.8 and 10.9 (and, likely, 10.7 or earlier):

patch-path-order.diff
patch-volk_lib_CMakeLists.txt.legacy.diff
patch-volk_gen_archs.xml.legacy.diff

Needed just for 10.9/libc++:

patch-gnuradio-core_swig_std_std_container.i.diff
patch-gnuradio-core_swig_include-std_string.i.diff

If you use those patches on your OOT build of GNU Radio, you should be
able to build it with minimal defines added to the cmake command line. -
MLD

8

Hi Arturo - Yes, I think you’ve nailed it. - MLD

9

Il 02/12/13 22:15, Michael D. ha scritto:

patch-gnuradio-core_swig_std_std_container.i.diff

to find if the patching is properly perfromed and the files are not affected by
patching. Now i have to figure out which are the right diff files to patch the
legacy version and the new version since I’m noticing that the source path
structure is different in the new tarball. Do I have to use all of them or not ?
Can i write just one single diff file to apply before building from source as
usual ? I was thinlking thah once the work is finished i could post it on the
mailing list so it’d be available for everyone…let me know if you like the
idea.

ok let’s sum up and see if i have understood what is coded in the
Portfile. Let’s examine it case by case :

10.7

*LEGACY (3.6.5.1 and lower) and *

/cat/ of :

patch-path-order.diff
patch-volk_lib_CMakeLists.txt.legacy.diff
patch-volk_gen_archs.xml.legacy.diff

then apply resulting patch, then build as usual

PS : I have always built from source any latest tarball of gnuradio
legacy successfully, so I don’t think I’ll ever apply this modifications

*NEW releases (3.7 and above)

*nothing to patch or to modify

10.8
*
LEGACY (3.6.5.1 and lower) and *

/cat/ of :

patch-path-order.diff
patch-volk_lib_CMakeLists.txt.legacy.diff
patch-volk_gen_archs.xml.legacy.diff

then apply resulting patch, then build as usual

*NEW releases (3.7 and above)

*nothing to patch or to modify (at least applying the swig/std “trick”
but it seems working without it as well)

10.9

first of all I have to perform the copy of the directory std of SWIG
in my source directory according to :

LEGACY*(3.6.5.1 and lower)*

cp -r /opt/local/share/swig/*/std to
/gnuradio-core/src/lib/swig

/cat/ of :

patch-path-order.diff
patch-volk_lib_CMakeLists.txt.legacy.diff
patch-volk_gen_archs.xml.legacy.diff
patch-gnuradio-core_swig_std_std_container.i.diff
patch-gnuradio-core_swig_include-std_string.i.diff

then apply resulting patch, then build as usual

NEW releases (3.7 and above)

cp -r /opt/local/share/swig/*/std to
/gnuradio-runtime/src/lib/swig

/cat/ of :

patch-gnuradio-runtime_swig_std_std_container.i.diff
patch-gnuradio-runtime_swig_include-std_string.i.diff

then apply resulting patch, then build as usual

Have I nailed it or not yet ? Let me know.

Regards, ARturo

10

Nella citazione in data Tue Dec 3 02:44:13 2013, Michael D. ha
scritto:

nothing to patch or to modify

LEGACY (3.6.5.1 and lower)

then apply resulting patch, then build as usual

Have I nailed it or not yet ? Let me know.

Thank you very much again for your support. You’re a priceless asset to
me and the whole gnuradio mailing list of course. Keep doing this great
work.

         Regards, Arturo