discuss-gnuradio
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]