discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] x86_64 issues I'd like input about.


From: Eric Blossom
Subject: Re: [Discuss-gnuradio] x86_64 issues I'd like input about.
Date: Tue, 21 Nov 2006 12:48:51 -0800
User-agent: Mutt/1.5.9i

On Mon, Nov 20, 2006 at 11:06:03PM -0500, David P. Reed wrote:
> Having updated to FC6 on my x86_64 laptop, I decided to play with the 
> install process there.   A couple of issues have arisen that I would be 
> interested in from folks who understand more about gnuradio than I.
> 
> 1. Thought most things are fine (as they have been in the past), 
> reviewing the test output, qa_feval.py fails in "make check".   This 
> seems to be due to gr.feval_dd not working.   Before I dig into 
> debugging it, am I correct in assuming it works on 32-bit platforms?   
> If so, it's one of those stupid 64-bit problems I keep finding in code 
> that is only lightly tested on 64-bit machines. 

I doubt it's a 64-bit problem.  I do most of my development on an
Opteron.  That said, I would like to know why it's failing.

Are you building the svn trunk?

What version of SWIG are you using?  

If it happens to be 1.3.30, please update to 1.3.31.  They had a
regression in 1.3.30.  Earlier versions should be fine too.


> 2. The problem with Fedora's x86_64 python library layout is well known, 
> but I found two approaches to work around it as I've been exploring the 
> depths of python search paths, etc.   One (which works like a charm) is 
> to put a gnuradio.pth file in lib64/site-packages, that contains:
> 
>    gnuradio
>    gnuradio/gr
>    gnuradio/vocoder
>    gnuradio/pager
>    ../../../lib/python2.4/site-packages/gnuradio
>    ../../../lib/python2.4/site-packages/gnuradio/gr
>    ../../../lib/python2.4/site-packages/gnuradio/vocoder
>    ../../../lib/python2.4/site-packages/gnuradio/pager
> 
> This forces all of the paths to be searched for imports.
> It's ugly, though it works.
> I think a better solution (which I will try shortly) is to put in in 
> each lib64 subdirectory (listed above) an __init__.py file that uses 
> pkgutils.extend_path()
> to force modules to search both lib64 and lib directories in parallel 
> for names.  I don't fully understand pkgutils.extend_path, but it seems 
> to be designed for just this purpose.

Thanks for the suggestions.

Eric




reply via email to

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