[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] make check test failures, Mac OS X, Python/SWIG
From: |
Stephane Fillod |
Subject: |
Re: [Discuss-gnuradio] make check test failures, Mac OS X, Python/SWIG |
Date: |
Wed, 12 Jan 2005 22:44:58 +0100 |
User-agent: |
Mutt/1.5.6+20040907i |
On Wed, Jan 12, 2005 at 11:28:48AM -0800, Jonathan Jacky wrote:
>
> I built gnuradio-core from CVS on Mac OS X.
[...]
> PS Here are the messages I got from "make check" after I built with swig
> 1.3.22. This first one seems to come from C++, so it is probably not
> related to swig:
>
> Making check in tests
> make check-TESTS
> .Testing gr_vmcircbuf_sysv_shm_factory...
> gr_vmcircbuf_sysv_shm: shmat (1): Too many open files
> gr_vmcircbuf_sysv_shm: shmget (1): Invalid argument
> gr_vmcircbuf_sysv_shm: shmat (1): Too many open files
> ....... gr_vmcircbuf_sysv_shm_factory: Failed
Can these system limits be pushed further? (I know next to nothing of OSX)
Have you tried the tricks at http://comsec.com/wiki?MacOsX ?
If you have at least one factory working, you can ignore the sysv_shm.
> Then here are the ones that seem to be related to swig:
>
> Making check in gr
> make check-TESTS
> Traceback (most recent call last):
> File "./qa_add_and_friends.py", line 23, in ?
> from gnuradio import gr, gr_unittest
> File
>
> "/Users/jon/gnuradio/gr-build/gnuradio-core/src/python/gnuradio/gr/__init__.py",
>
> line 27, in ?
> from gnuradio_swig_python import *
> File
>
> "/Users/jon/gnuradio/gr-build/gnuradio-core/src/lib/swig/gnuradio_swig_python.py",
>
> line 5, in ?
> import _gnuradio_swig_python
> ImportError: Failure linking new module: : dyld: python Undefined
> symbols:
> _SWIG_Python_ConvertPtr
> _SWIG_Python_InstallConstants
> _SWIG_Python_NewPointerObj
> _SWIG_Python_TypeClientData
> _SWIG_Python_TypeQuery
> _SWIG_Python_TypeRegister
> _SWIG_Python_addvarlink
> _SWIG_Python_newvarlink
Under Cygwin and MinGW, I fixed this problem with the attached patch.
The "-no-undefined" are required for win32 system, harmless under others.
The "address@hidden@" is what may solve your problem. Make sure
the library is in your linker path (maybe autoconf should check
whether "address@hidden@" links fine).
Eric, what are your thoughts about this?
--
Stephane
pythonwin.patch
Description: Text document