[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Custom block problem on OSX 10.6
From: |
Kunal Kandekar |
Subject: |
Re: [Discuss-gnuradio] Custom block problem on OSX 10.6 |
Date: |
Sat, 20 Feb 2010 21:18:24 -0500 |
Hi Michael,
Thanks for looking into it. I don't have access to a 10.5 32-bit machine to test it out on at the moment (is there anything I can do with the configuration?) However, I had built and tested my code on a 10.5 32-bit machine, and it worked fine then. I have not changed the code itself since I moved to the new Snow Leopard machine, but I did have to play with the configuration to get it to compile. Basically I had to force a 64-bit build, and override pkg-config to get Makefile to use the macports gnuradio install. This is the configure command I ran in my custom block directory:
./configure --build=i686-apple-darwin10 --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 LDFLAGS=-L/opt/local/lib CFLAGS=-I/usr/include/python2.6 CXXFLAGS=-I/usr/include/python2.6 --with-pythondir=/opt/local/lib/python2.6/site-packages GNURADIO_CORE_INCLUDEDIR=/opt/local/include/gnuradio GNURADIO_CORE_LIBS=/opt/local/lib
I had the same error for howto-write-a-block (with the same configure command) as I did my custom block, so I suspect a problem in the install or my configuration.
Kunal
On Sat, Feb 20, 2010 at 2:03 PM, Michael Dickens
<address@hidden> wrote:
Hi Kunal - I can't directly address the question of whether or not custom blocks work on OSX 10.6 x86_64, since I've never compiled by custom blocks under that OS (yet). I need to do some 10.6 x64 work anyway, so I'll try out my blocks later today & see what happens.
Not sure if this makes any difference, but one of the errors seems to be:
File "/opt/local/lib/python2.6/site-packages/gnuradio/gr/gnuradio_swig_py_runtime.py", line 1487, in connect
return _gnuradio_swig_py_runtime.gr_top_block_sptr_connect(self, *args)
NotImplementedError: Wrong number of arguments for overloaded function 'gr_top_block_sptr_connect'.
Possible C/C++ prototypes are:
connect(boost::shared_ptr< gr_top_block > *,gr_basic_block_sptr)
connect(boost::shared_ptr< gr_top_block > *,gr_basic_block_sptr,int,gr_basic_block_sptr,int)
so ... maybe in your QA code you're creating a bad connection?
If you go back to 10.5 32-bit, does your custom block work correctly?
- MLD