This is a bug fix and very minor enhancement release to the existing 3.0
stable branch. All relevant issues that have been corrected on the main
development trunk have been back-ported.
Details on the changes since release 3.0.2 are listed here:
Unfortunately, this release candidate does not include a fix for
ticket:39 (/lib vs /lib64 issues on Fedora Core 5 and 6). Those
developers who are affected by this issue and can perform testing of
potential fixes should contact Eric B…
As usual, please report any problems via the Trac ticket system, using
the ‘guest’ account with password ‘gnuradio’:
Unfortunately, this release candidate does not include a fix for
ticket:39 (/lib vs /lib64 issues on Fedora Core 5 and 6). Those
developers who are affected by this issue and can perform testing of
potential fixes should contact Eric B…
I’ve created jcorgan/ticket-39 for this, but there are no fixes
checked-in yet. I’ve taken ownership of this ticket from Eric; I’ll
follow up with you off-list.
On Wed, Feb 21, 2007 at 10:37:58AM -0800, Johnathan C. wrote:
Trond D. wrote:
Is there a branch where a fix is being developed?
I’ve created jcorgan/ticket-39 for this, but there are no fixes
checked-in yet. I’ve taken ownership of this ticket from Eric; I’ll
follow up with you off-list.
On OSX 10.4.8, both Intel and PPC Macs, 3.0.3rc1 does everything as
expected except “make check” as per ticket:140, including:
configure
configure --prefix=FOO
make
make -j3
after “make install” (which puts the gr-usrp library where it expects
itself to be), the following also work:
make check
make distcheck
I have not tried these installed for functionality, but I would
assume they function as well as the SVN trunk. - MLD
ps> I’m close to having a MacPorts portfile available for GNU Radio,
which “does it all” … but there’s a current conflict between
wxWidgets and wxPython that is challenging to resolve. I’ll let the
list know if/when I get this resolved … until then I doubt that the
GR portfile will work for gr-wxgui. But if anyone (running OSX,
obviously) wants to try this out let me know & I’ll send it on.
After some beta testing, I will submit it to the MacPorts project.
Traceback (most recent call last):
File “./qa_fft_filter.py”, line 191, in test_fff_002
self.fg.run()
File
“/usr/src/gnuradio/gnuradio-3.0.3rc1/gnuradio-core/src/python/gnuradio/gr/flow_graph.py”,
line 112, in run
self.start ()
File
“/usr/src/gnuradio/gnuradio-3.0.3rc1/gnuradio-core/src/python/gnuradio/gr/flow_graph.py”,
line 93, in start
self.scheduler.start ()
File
“/usr/src/gnuradio/gnuradio-3.0.3rc1/gnuradio-core/src/python/gnuradio/gr/scheduler.py”,
line 57, in start
thread.start()
File
“/usr/src/gnuradio/gnuradio-3.0.3rc1/gnuradio-core/src/python/gnuradio/gr/gr_threading_24.py”,
line 420, in start
_start_new_thread(self.__bootstrap, ())
error: can’t start new thread
another issue already highlighted by Greg Toxel is
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_factory: Doesn’t work
Testing gr_vmcircbuf_mmap_shm_open_factory…
On Thu, Feb 22, 2007 at 02:43:09PM +1030, Berndt Josef W. wrote:
self.fg.run()
line 57, in start
thread.start()
File “/usr/src/gnuradio/gnuradio-3.0.3rc1/gnuradio-core/src/python/gnuradio/gr/gr_threading_24.py”,
line 420, in start
_start_new_thread(self.__bootstrap, ())
error: can’t start new thread
Not sure about those…
Sounds like you are running out of some system resource.
another issue already highlighted by Greg Toxel is
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_factory: Doesn’t work
Testing gr_vmcircbuf_mmap_shm_open_factory…
Those aren’t (hard) failures. They just indicate that under stress
testing your shm* stuff won’t work. Greg posted a note to the list a
while ago about how to bump up the default number of shm segments
available. When shm* doesn’t work, we use other techniques such as
shm_open or mmap’ing a tmp file.
On Wed, Feb 21, 2007 at 09:29:44PM -0500, Michael D. wrote:
make check
make distcheck
I have not tried these installed for functionality, but I would
assume they function as well as the SVN trunk. - MLD
Johnathan or Michael, can you take a look at ticket:140.
I suspect that run_tests.sh is missing the usrp directory when it sets
DYLD_LIBRARY_PATH
ps> I’m close to having a MacPorts portfile available for GNU Radio,
which “does it all” … but there’s a current conflict between
wxWidgets and wxPython that is challenging to resolve. I’ll let the
list know if/when I get this resolved … until then I doubt that the
GR portfile will work for gr-wxgui. But if anyone (running OSX,
obviously) wants to try this out let me know & I’ll send it on.
After some beta testing, I will submit it to the MacPorts project.
Thanks for the update.
For the *Ports challenged, what’s the difference between MacPorts and
DarwinPorts?
Johnathan or Michael, can you take a look at ticket:140.
I suspect that run_tests.sh is missing the usrp directory when it sets
DYLD_LIBRARY_PATH
I don’t have much time today, but I’ll try to take a look mid-day or
this evening when I have a free hour. Or not at all if Johnathan
gets there first.
I will also today try to run some tests on a PPC Mac, since I seem to
remember that it didn’t work the last time I tried. GR does run fine
on an Intel-Mac, as I was working on one yesterday.
For the *Ports challenged, what’s the difference between MacPorts and
DarwinPorts?
They’re changing their name from DP to MP … and going through a
rough transition in the process too. It used to be true that Fink
was almost always “behind” on the latest releases while DP was almost
always “on top of” them. During this transition, MP is having
trouble keeping up with the latest. I’ve posted patches for the
portfiles that are of use to me - those for GNU Radio and
OpenEmbedded - but even those take up to a week to propagate through
the system, and then sometimes things have changed again so the patch
is already out of date. I’m trying to get signed up to be a MP
developer, so-as to be able to have commit access for those portfiles
for GR and OE, but that also takes a long time.
Q?> For install systems such as DPKG or DP/MP, where should “gnuradio-
examples” be installed? Right now it’s -not- installed … so I was
thinking ${prefix}/share/gnuradio would make the most sense. I can
do this manually in DP/MP, as a “post-install” task.
On Thursday 22 February 2007 15:18, Eric B. wrote:
Traceback (most recent call last):
/flow_graph.py", line 93, in start
_start_new_thread(self.__bootstrap, ())
… gr_vmcircbuf_sysv_shm_factory: Doesn’t work
Thanks,
Eric
Greg’s suggestion of bumping the values for shmmni and shmseg helped to
solve
the shmat(1) related matter. shmget(1) still fails with “invalid
argument”
when the second parameter of shmget evaluates to 8396800 - e.g.
Johnathan - Yes, that works; thank you. BTW> The change that you
made also renders the PATH in gr-usrp’s run_tests.in redundant.
Okay.
Might it not be better instead for run_tests.in in gr-usrp to specify
the USRP libraries to include in the DYLD path instead of doing that
(for all modules) in the top-level run_tests.sh file? - since not
all modules rely upon the USRP but all do (for now) upon
gnuradio-core?
You’re correct. It was a pre-morning-cup-of-coffee type of fix. I will
make the change you recommend on the trunk in a few minutes so you can
retest.
On Thu, Feb 22, 2007 at 02:17:30PM -0500, Michael D. wrote:
(for all modules) in the top-level run_tests.sh file? - since not all
modules rely upon the USRP but all do (for now) upon gnuradio-core?
I guess what I’m thinking of is to move all of the module-specific
stuff into each module, and leave the top-level run_tests to hold all
common stuff. These are not big or difficult changes, if you want me
to give it a go. - MLD
I think you’re right.
I suspect that the change that mattered is only the DYLD_LIBRARY_PATH
one. I’d like to go with the minimum fix. Otherwise, down the road
it’s hard to figure out which of the stuff added really needed to be
there.
please update to trunk revision 4588 and retest ticket:140.
I’ll need to do an equivalent fix in the release 3.0 branch if this
works for you.
Johnathan - Yes, that works; thank you. BTW> The change that you
made also renders the PATH in gr-usrp’s run_tests.in redundant.
Might it not be better instead for run_tests.in in gr-usrp to specify
the USRP libraries to include in the DYLD path instead of doing that
(for all modules) in the top-level run_tests.sh file? - since not all
modules rely upon the USRP but all do (for now) upon gnuradio-core?
I guess what I’m thinking of is to move all of the module-specific
stuff into each module, and leave the top-level run_tests to hold all
common stuff. These are not big or difficult changes, if you want me
to give it a go. - MLD
On Thu, Feb 22, 2007 at 04:02:11PM -0500, Michael D. wrote:
It looks like there is a typo in gnuradio-core/src/lib/general/
Makefile* or Makefile.common … but I don’t have time right now to
look into this. I have to run now, but I’ll check this out again
tonight. - MLD
Any chance there’s a ’ ’ in any of the path names?
Eric
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
