Forum: GNU Radio GNU Radio Using MacPorts

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

Nella citazione in data Tue Nov 20 20:35:14 2012, Michael Dickens 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
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>

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:
    http://guide.macports.org/#project.tickets
Error: Processing of port gnuradio failed

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

Thanks in advance, Arturo

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

Nella citazione in data Wed Nov 21 01:44:00 2012, Michael Dickens 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.

> 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/M...

-josh

> 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

> 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/M...

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.

On Tue, Nov 20, 2012 at 2:35 PM, Michael Dickens <mlk@alum.mit.edu> 
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/<component>

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=<your destination>":

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

>
# 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

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

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

On Wed, Nov 21, 2012 at 1:35 PM, Josh Blum <josh@ettus.com> 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

On 11/21/2012 04:27 AM, Michael Dickens wrote:
>
Found another problem include: http://pastebin.com/FYvr5Sbs

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

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

On Thu, Nov 22, 2012 at 10:20 AM, Carles Fernandez <
carles.fernandez@gmail.com> 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

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 Corgan

On Nov 22, 2012, at 4:00 AM, Ian Buckley <ianb@ianbuckley.net> 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

Nella citazione in data Fri Nov 23 17:35:38 2012, Michael Dickens ha
scritto:
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>

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 ?

On Nov 26, 2012, at 5:30 PM, Arturo Rinaldi <arty.net2@gmail.com> wrote:
> 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.

Great!

> 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

Nella citazione in data Tue Nov 27 00:36:33 2012, Michael Dickens 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: fcn[1]()
  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

On Nov 22, 2012, at 11:57 AM, Josh Blum <josh@ettus.com> wrote:
> Found another problem include: http://pastebin.com/FYvr5Sbs
>
> 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

On Nov 22, 2012, at 9:53 AM, Tom Rondeau <tom@trondeau.com> wrote:
> Yes, that's better. More what I was going for originally, too. Thanks.
Thanks for adding that variable in.  Works nicely.  I'll update the 
Portfile. - MLD

Hi Arturo - Can you load up the GRC example provided by GR: 
gnuradio/examples/grc/simple/variable_config.grc ?  This file works just 
fine for me, no GL issues or anything, and it looks about the same as 
your figure (or, maybe I'm doing something wrong?).  I'm running from 
the latest GIT master (as installed by MacPorts "gnuradio-devel +full"; 
just updated this morning!).  If this gives you the same error, then 
either email me off-list and we can work on resolving it; or, create a 
ticket in MacPorts and assign me as the owner and I'll work with you 
there. - MLD

Nella citazione in data Thu Nov 29 02:24:03 2012, Michael Dickens ha
scritto:
>> 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
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>

I need some details about your configuration. Mine is the following :

iMac 21" with MacOs X Lion 10.7.5 and MacPorts 2.1.2

i was wondering if this issue is due to the fact that i can only
install wxWidgets-devel an wxpython-devel, the 2.9.4.0 version, since
Macports itself is unable to build the 2.8.12 version on Lion 10.7 and
Xcode > 4.4 by default......any ideas about it ?. I'll keep you updated
as soon as i perform some tests on my setup.

Regards, Arturo

Nella citazione in data Thu Nov 29 23:31:58 2012, Arturo Rinaldi ha
scritto:
>> owner and I'll work with you there. - MLD
>>> File
>>> I get the controls part but not the plotting part of the sink :
>>
> updated as soon as i perform some tests on my setup.
>
> Regards, Arturo

I am currently testing two installations :

sudo port install gnuradio +full +python27
configure.compiler=llvm-gcc-4.2 -v

and

sudo port install gnuradio-devel +full +python27
configure.compiler=llvm-gcc-4.2 -v

you're totally right about "variable_config.grc", it's pretty much the
same flow graph as mine....

Arturo