discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] gr-audio-oss segfaults


From: Eric Blossom
Subject: Re: [Discuss-gnuradio] gr-audio-oss segfaults
Date: Thu, 6 Apr 2006 19:05:59 -0700
User-agent: Mutt/1.5.9i

On Fri, Apr 07, 2006 at 07:50:53AM +0930, Berndt Josef Wulf wrote:
> G'day,
> 
> gr-audio-oss segfaults when built using the gr-audio-oss-0.8.tar.gz tarball. 
> The reason for this is that the tarball includes audio_oss.cc which normally 
> is created by swig. Consequently, the interfaces created in this file may not 
> be correct for the  every target system. I guess this was overlooked during 
> the  creation of the tarball.
> 
> It would be nice if we can create a new tarball e.g gr-audio-oss-0.8.1.tar.gz 
> that excludes this file. I believe that package maintainers would appreciate 
> this.
> 
> cheerio Berndt


Hi Berndt,

After taking a look at this, I think the problem is in the
gnuradio-core build process.  All the tarballs that I checked
designate the swig generated output files as BUILT_SOURCES, and all
contain the output of running swig on the machine I built the tarballs
on.

That part is right.

The part that's wrong, is that something in the gnuradio-core build
process is triggering a dependency that's having gnuradio-core's swig
output be regenerated.  This could lead to a situation where
gnuradio-core's stuff is built with one version of swig, while all the
others use a different version.  I suspect that some of the machine
generated code (particularly the .i and .h files) in general and/or
filter isn't labeled BUILT_SOURCES, and thus isn't in the tarball.
Building that stuff would then force swig to be run, causing the
potential swig version inconsistency.


I'll continue to investigate, but not right now.  


If someone else wants to help sort this out, please dive in.

BTW, this problem isn't new.  It's been in all the tarballs generated
over the last couple of years.  I think we're seeing it now because I
used swig 1.3.29 on the build machine.  The swig generated code changed
for the better between 1.3.27 and 1.3.28.


Thanks again for noticing & reporting the problem,
Eric




reply via email to

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