GNU Radio Using MacPorts

[aris]

I just updated the GNU Radio ports in MacPorts to the latest release
(3.6.2), GIT master (commit afea463f07), and GIT Next branch (commit
c0b35b4ec7). By using a single Portfile for all 3 versions, I should be
able to maintain the ports more easily and keep the more up to date as
releases and GIT commits happen.

If you’re using OSX, any version though MacPorts targets 10.5 and newer,
I would appreciate your feedback as to whether these ports work for you
or not. Well, OK, the Next port won’t yet due to some issue with Boost
and the real time clock; but, this is known to GR developers and they’re
working on it (right?). The other ports should work, with GCC or Clang
as you like.

Along the way, I came upon 3 issues:

1. Clang and ASM don’t play nice with “.version” commands. Tom has
   already addressed this in a patch, but it’s not yet in the GIT master or
   next branch. I am using that patch in my port until it is no longer
   necessary.

2. If GNU Radio is already installed (e.g., by MacPorts), then
   <gruel/*.h> will be picked up as dependencies from the already-installed
   files rather than from the current build. I work around this (at least
   partially) by modifying the CMake “build.make” dependencies to be the
   correct files (those in the current build). I’ve looked at the build
   debug output, and it seems OK – so, I’m thinking this is more of a
   CMake internal issue (in the way it determines dependencies) rather than
   a GNU Radio CMake build script issue (in the ordering of dependency
   directories). But, maybe not? Anyway, thought folks might want to
   know. I know I’ve encountered this issue before; it requires that one
   uninstall GNU Radio, re-do the CMake command, and then the build works.

3. Python scripts are installed into
   ${prefix}/lib/pythonX.Y/site-packages . Always. And I cannot change
   this setting to the best of my reading. I use a post-destroot hook that
   moves the whole site-packages directory into the appropriate Python
   MacPorts framework directory. It would be good to be able to control
   where these files are placed via some CMake command-line option.

Enjoy! - MLD

[mdeering]

Nella citazione in data Tue Nov 20 20:35:14 2012, Michael D. ha
scritto:

3. Python scripts are installed into ${prefix}/lib/pythonX.Y/site-packages .
   Always. And I cannot change this setting to the best of my reading. I use a
   post-destroot hook that moves the whole site-packages directory into the
   appropriate Python MacPorts framework directory. It would be good to be able to
   control where these files are placed via some CMake command-line option.

Enjoy! - MLD

---

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

FIRST ERROR on Lion 10.7.5 and MacPorts 2.1.2, can’t fetch teh patch
file :

Error: org.macports.fetch for port gnuradio returned: fetch 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:
MacPorts Guide
Error: Processing of port gnuradio failed

any ideas ? do i have to wait some time beacuse of server side issues ?

Thanks in advance, Arturo

[mdeering]

That would be my bad. I just checked in that file, so it will appear
when you do a selfupdate within 30 minutes from this email. Things will
work a LOT better when that file is available. - MLD

[mdeering]

Nella citazione in data Wed Nov 21 01:44:00 2012, Michael D. ha
scritto:

any ideas ? do i have to wait some time beacuse of server side issues ?

Sorry Michael, you’re totally right. I thought it was all ready to
install when you sent the email to the mailing list. Apologies again
and keep up with the great work :D.

Regards, Arturo.

[mdeering]

Anyway, thought folks might want to know. I know I’ve encountered
this issue before; it requires that one uninstall GNU Radio, re-do
the CMake command, and then the build works.

I just recently caught one of these order of include paths in
gr-uhd/swig. Its so easy to accidentally get it in the wrong order. I’d
like to take a look: Can you say what component is pulling in the
installed headers? Is it a specific component, swig module, etc?

Also; There is also a little swig dependency searcher at the bottom of
GrSwig.cmake. I wrote this, and its got its flaws. If you configure,
uninstall some public headers, and try to build, you may get an error
until you reconfigure…

http://gnuradio.org/cgit/gnuradio.git/tree/cmake/Modules/GrSwig.cmake#n200

-josh

[mdeering]

Sorry Michael, you’re totally right. I thought it was all ready to install when
you sent the email to the mailing list. Apologies again and keep up with the great
work :D.

No problems, and thanks! We all do the best we can, and sometimes we
just forget the small things. I certainly do - MLD

[mdeering]

I just recently caught one of these order of include paths in
gr-uhd/swig. Its so easy to accidentally get it in the wrong order. I’d
like to take a look: Can you say what component is pulling in the
installed headers? Is it a specific component, swig module, etc?

Watching the debug output of the post-configure hook, which effectively
issues a “sed” script to do the replacement, everything is effected. It
looks like the files of issue are “${prefix}/include/gruel/*.h”.

Also; There is also a little swig dependency searcher at the bottom of
GrSwig.cmake. I wrote this, and its got its flaws.

I hadn’t found that yet; I’ll try to look at that today since it would
be great to get this done. Dependencies are a pain; I remember that
distinctly when I (re)wrote the prior build system.

If you configure,
uninstall some public headers, and try to build, you may get an error
until you reconfigure…

http://gnuradio.org/cgit/gnuradio.git/tree/cmake/Modules/GrSwig.cmake#n200

Yes, that’s how I was testing for this issue. I’d do what you wrote,
then patch the “build.make” files until CMake was happy, then try again
while watching the debug output; repeat. That’s how I found it was just
gruel headers.

• MLD

ps> While we’re on the subject of the build system, can I suggest a
slight change to the printouts? I’ll search around a little this
morning to see if I can change this myself, but maybe someone else
(e.g., Josh) knows quickly where to look and how to change this.

What I’d like to see is if I disable a component on the cmake command
line (e.g., “cmake -DENABLE_VOLK=NO”), then in the message printout is
says that that component was disabled by the user (e.g., “Volk was
disabled by the user.”) or something like that. Right now it just says
that the component was disabled even if everything else was found –
and, thus, it’s not clear where the issue might be (e.g, maybe it was
something internal that isn’t listed?). Stating that it was the user’s
explicit choice to disable the component would be good from a debug
standpoint.

It would also be nice to not even do the checks for that component if it
is disabled by the user. Since each component’s checks are independent
(or, should be), this should be no issue. I see that this happens with
some components (e.g., gnuradio-core) but not others; or, at least
partially they do.

[mdeering]

On Tue, Nov 20, 2012 at 2:35 PM, Michael D. [email protected]
wrote:

I just updated the GNU Radio ports in MacPorts to the latest release (3.6.2),
GIT master (commit afea463f07), and GIT Next branch (commit c0b35b4ec7). By using
a single Portfile for all 3 versions, I should be able to maintain the ports more
easily and keep the more up to date as releases and GIT commits happen.

If you’re using OSX, any version though MacPorts targets 10.5 and newer, I would
appreciate your feedback as to whether these ports work for you or not. Well, OK,
the Next port won’t yet due to some issue with Boost and the real time clock; but,
this is known to GR developers and they’re working on it (right?). The other
ports should work, with GCC or Clang as you like.

Thanks for the good work!

Along the way, I came upon 3 issues:

1. Clang and ASM don’t play nice with “.version” commands. Tom has already
   addressed this in a patch, but it’s not yet in the GIT master or next branch. I
   am using that patch in my port until it is no longer necessary.

Well, no complaints on this branch so far. I’ve been letting it sit
for a while, but as is always the case, we won’t get good test
coverage until we merge it in.

2. If GNU Radio is already installed (e.g., by MacPorts), then <gruel/*.h> will
   be picked up as dependencies from the already-installed files rather than from the
   current build. I work around this (at least partially) by modifying the CMake
   “build.make” dependencies to be the correct files (those in the current build).
   I’ve looked at the build debug output, and it seems OK – so, I’m thinking this is
   more of a CMake internal issue (in the way it determines dependencies) rather than
   a GNU Radio CMake build script issue (in the ordering of dependency directories).
   But, maybe not? Anyway, thought folks might want to know. I know I’ve
   encountered this issue before; it requires that one uninstall GNU Radio, re-do the
   CMake command, and then the build works.

3. Python scripts are installed into ${prefix}/lib/pythonX.Y/site-packages .
   Always. And I cannot change this setting to the best of my reading. I use a
   post-destroot hook that moves the whole site-packages directory into the
   appropriate Python MacPorts framework directory. It would be good to be able to
   control where these files are placed via some CMake command-line option.

This should be the GR_PYTHON_DIR variable. All of the install rules
for Python files have:

DESTINATION ${GR_PYTHON_DIR}/gnuradio/

This always gets set in GrPython.cmake, but this simple patch would
allow us to set it on the cmake command line with
“-DGR_PYTHON_DIR=”:

diff --git a/cmake/Modules/GrPython.cmake b/cmake/Modules/GrPython.cmake
index 14f2b29…5287955 100644
— a/cmake/Modules/GrPython.cmake
+++ b/cmake/Modules/GrPython.cmake
@@ -96,11 +96,13 @@ endmacro(GR_PYTHON_CHECK_MODULE)
########################################################################

Sets the python installation directory GR_PYTHON_DIR

########################################################################
+if(GR_PYTHON_DIR STREQUAL “”)
execute_process(COMMAND ${PYTHON_EXECUTABLE} -c "
from distutils import sysconfig
print sysconfig.get_python_lib(plat_specific=True, prefix=‘’)
" OUTPUT_VARIABLE GR_PYTHON_DIR OUTPUT_STRIP_TRAILING_WHITESPACE
)
+endif()
file(TO_CMAKE_PATH ${GR_PYTHON_DIR} GR_PYTHON_DIR)

########################################################################

I’m not sure if this is the ‘cmake way’ of doing something like this,
but it’s simple and works.

Tom

[mdeering]

Hi there,

I’ve just tried the variants:

sudo port install gnuradio +grc +python27 +uhd +orc +swig

and everything seems to work fine, including gnuradio-companion (which I
lost in Mac OS for ages). Thanks Michael for this great job!

Just a question: when I ran volk_profile, I notice that only generic and
some orc implementations are available, with lots of ‘no architectures
to
test’. Does someone has achieved to use sse3 implementations in Mac OS?

Best regards,
Carles

[mdeering]

Sets the python installation directory GR_PYTHON_DIR

########################################################################

+if(GR_PYTHON_DIR STREQUAL “”)

I’m not sure if this is the ‘cmake way’ of doing something like
this, but it’s simple and works.

That seems like the right idea to me, we already do this for
PYTHON_EXECUTABLE.

I would just do if(NOT DEFINED GR_PYTHON_DIR)

Otherwise, cmake might be kind of funny when the var is undefined.

-josh

[mdeering]

Hi Carles - Thanks for the report; I’m glad it works for you! If you
installed the “gnuradio” port using XCode 4.5 or newer (maybe even 4.4
or newer), then Apple’s Clang is the default compiler suite. IIRC, Volk
and Clang do not play nicely together yet; Volk (at least as of the
3.6.2 release) will enable SSE and related instructions when compiled
using gcc only. Which you can do if you want to IIRC by appending
“configure.compiler=apple-gcc-4.2” to the end of your "sudo port install
" command line. Or, you could choose “llvm-gcc-4.2” instead which should
also work. I haven’t tried either of these yet, so if you do I’d love
to hear about what happens. - MLD

[mdeering]

On Wed, Nov 21, 2012 at 1:35 PM, Josh B. [email protected] wrote:

${GR_PYTHON_DIR} GR_PYTHON_DIR)
PYTHON_EXECUTABLE.

I would just do if(NOT DEFINED GR_PYTHON_DIR)

Otherwise, cmake might be kind of funny when the var is undefined.

-josh

Yes, that’s better. More what I was going for originally, too. Thanks.

Tom

[mdeering]

Hi all,

I’ve tried (in Mac OS X 10.8.2, Xcode 4.5.2 with up-to-date Command Line
Tools):

$ sudo port install gnuradio +grc +python27 +uhd +orc +swig
configure.compiler=llvm-gcc-4.2

Everything built smoothly. Now when I do volk_profile, the sse
implementations are there and accelerate some volk instructions
considerably. I’m happier than a kid in a candy store

Carles

[mdeering]

On 11/21/2012 04:27 AM, Michael D. wrote:

Found another problem include: diff --git a/gruel/CMakeLists.txt b/gruel/CMakeLists.txtindex 3e8c516..627135a - Pastebin.com

Any dependency adding GRUEL_INCLUDE_DIRS to the include path might have
been causing ${Boost_INCLUDE_DIRS} to take precedence over local
directories. And who knows what might also be in ${Boost_INCLUDE_DIRS}

-josh

[mdeering]

On Thu, Nov 22, 2012 at 10:20 AM, Carles Fernandez <
[email protected]> wrote:

I’m happier than a kid in a candy store

GNU Radio does that sometimes. We’ve been trying to track down the bug
but
it has eluded us for years

Johnathan

[mdeering]

On Nov 22, 2012, at 4:00 AM, Ian B. [email protected] wrote:

I have Xcode4.5 installed so I gave the “configure.compiler=apple-gcc-4.2” idea
a go.

Well, that was “my bad”: “apple-gcc-4.2” is MacPorts’ install of GCC 4.2
with Apple modifications. Not generally what you want to be using.
Since you’re using Xcode 4.5, I’d recommend instead using
“configure.compiler=llvm-gcc-4.2”, which uses “/usr/bin/llvm-gcc-4.2”.
For those folks using older Xcode, I’d recommend using
“configure.compiler=gcc-4.2” which (IIRC) uses “/usr/bin/gcc-4.2”.
Sorry for the mix-up; I think the MacPorts names for the various
compiler suites could use a little work and/or better description, but
that’s not up to me. - MLD

[mdeering]

Relieved to hear that. I’ve been struggling with clang and volk for a
long
time with no success. I learned a lot in the process, though

On Thu, Nov 22, 2012 at 7:25 PM, Johnathan C.

[mdeering]

Nella citazione in data Fri Nov 23 17:35:38 2012, Michael D. ha
scritto:

Discuss-gnuradio Info Page

I smoothly installed the port version with

sudo port install gnuradio +docs +grc +python27 +qtgui +wxgui +uhd
+volk +wavelet +jack +portaudio +swig +sdl
configure.compiler=llvm-gcc-4.2

performing a full installation. Now my question is, is there a way to
use the GL sinks (scopesink, fftsink and so on) ? Every time i run a
flow graph containing one of these elements, i get a OpenGL error and
its pyton binding…any hint to solve this issue ?

[mdeering]

Nella citazione in data Tue Nov 27 00:36:33 2012, Michael D. ha
scritto:

Now my question is, is there a way to use the GL sinks (scopesink, fftsink and
so on) ? Every time i run a flow graph containing one of these elements, i get a
OpenGL error and its pyton binding…any hint to solve this issue ?

Can you post the console error message so that we can see what’s going on, as
well as what you were trying to do when you got the error? - MLD

Ok let’s do just a simple flow graph. Here’s the screenshot :

http://img594.imageshack.us/img594/5670/testnz.png

I’m trying to display a simple cosine waveform in a WXGUI Scopesink.
This is the error I get when I run the flow graph :

Traceback (most recent call last):
File
“/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/wxgui/plotter/plotter_base.py”,
line 187, in _on_paint
for fcn in self._draw_fcns: fcn1
File
“/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/wxgui/plotter/plotter_base.py”,
line 58, in draw
GL.glNewList(self._grid_compiled_list_id, GL.GL_COMPILE)
ctypes.ArgumentError: argument 1: <type ‘exceptions.TypeError’>: wrong
type

I get the controls part but not the plotting part of the sink :

http://img842.imageshack.us/img842/2728/test2xm.png

No issues apparently with QT SINKS.

Regards, Arturo

[mdeering]

On Nov 22, 2012, at 11:57 AM, Josh B. [email protected] wrote:

Found another problem include: diff --git a/gruel/CMakeLists.txt b/gruel/CMakeLists.txtindex 3e8c516..627135a - Pastebin.com

Any dependency adding GRUEL_INCLUDE_DIRS to the include path might have
been causing ${Boost_INCLUDE_DIRS} to take precedence over local
directories. And who knows what might also be in ${Boost_INCLUDE_DIRS}

Good catch. Still doesn’t take care of the original issue (just tested
it out now, with the latest GIT master). - MLD