X86_64 issues I'd like input about

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.

  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.

2006/11/21, David P. Reed [email protected]:

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.

Does this work? I tried adding the python header file, but it did not
work. Anyway I think the best solution is to install both the
extention modules and the scripts in the same folder (lib64), since
the way fedora installs python libs on fc6 is wrong. I have created a
patch that takes care of this, it should also work on i386.

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.

…/…/…/lib/python2.4/site-packages/gnuradio/gr
to be designed for just this purpose.
Thanks for the suggestions.

Eric

Eric - here is the simplest test I can give, it fails by printing “Fired
= false” and nothing else.

On Wed, Nov 22, 2006 at 10:53:21AM -0500, David P. Reed wrote:

Eric - here is the simplest test I can give, it fails by printing “Fired
= false” and nothing else.

if name == ‘main’:
f = my_feval()
gr.feval_example(f)
print "fired = "+f.fired

Weird. On my Opteron it says “fired = True”

What version of Python are you using?
I haven’t done any testing with 2.5 yet.

This particular test code exercises SWIG “directors” but also
exercises a bit of a kludge the acquires and releases the Python
“Global Interpreter Lock”. That the lock part must be working OK,
otherwise you’d see SIGSEGV.

Perhaps there is some kind of stale install problem?
Can you try removing all of the gnuradio related stuff under
/usr/local/lib{,64}/python/site-packages as well as the
/usr/local/lib64/libgnuradio*, then make again?

Eric

Eric -

Though Fedora Core 6 has swig 1.3.29 as its current release level, I
updated swig on my machine to swig-1.3.31 from swig.org. This fixed
the gr_feval bug on my x86_64 machine.

I put in a ticket on this (106). But someone who doesn’t re run
bootstrap in the build won’t discover the problem.

On Wed, Nov 22, 2006 at 06:01:14PM -0500, David P. Reed wrote:

Eric -

Though Fedora Core 6 has swig 1.3.29 as its current release level, I
updated swig on my machine to swig-1.3.31 from swig.org. This fixed
the gr_feval bug on my x86_64 machine.

I put in a ticket on this (106). But someone who doesn’t re run
bootstrap in the build won’t discover the problem.

Thanks.

What version of Python ships with Fedora Core 6?

Eric

2006/11/23, David P. Reed [email protected]:

This seems to me to be clean and “correct”. It has the result that if
you are running a 32-bit version of python, you just leave lib64 out of
PYTHONPATH and the 64-bit-specific code will not be found first.
(Fedora should have a lib32/python2.4/site-packages, but it depends on
path ordering to do that).

Despite the fact that this solution works, I do not think it is
“correct”. No python application distributed by Fedora is split
between lib and lib64. Packages are either installed in lib or lib64.
The only time packages appare to be split between the two folders is
when both the i386 and x86_64 version is installed. From what I know,
SuSE also install x86_64 python programs only in lib64. I therefore
think the correct solution would be to install everything either in
lib64 or in lib.


Trond D.

Eric -

A very clean fix for the path problem on Fedora x86_64 machines is as
follows:

in each directory in site-packages/gnuradio modify the init.py file
to include the following two lines as the first lines after the
comments:

import pkgutil
path = pkgutil.extend_path(path, name)

and then if the pyexecdir is different from pythondir, create symbolic
links from each directory created in pyexecdir to init.py in the
corresponding directory in pythondir (you could just copy init.py).

What this does, for example, is put the above two lines in
…/lib/python2.4/site-packages/gnuradio/gr/init.py amd a symbolic
link to that file in …/lib64/python2.4/site-packages/gnuradio/gr
(where the arch-dependent compiled files are installed).

Thus, when you do

 from gnuradio import gr

the path gets changed in the init.py to include both directories,
and thus gr’s pieces all do imports that search both directories.

This seems to me to be clean and “correct”. It has the result that if
you are running a 32-bit version of python, you just leave lib64 out of
PYTHONPATH and the 64-bit-specific code will not be found first.
(Fedora should have a lib32/python2.4/site-packages, but it depends on
path ordering to do that).

I have tested this and it works swell.

On Wed, Jan 17, 2007 at 01:57:30PM +0100, Trond D. wrote:

“correct”. No python application distributed by Fedora is split
between lib and lib64. Packages are either installed in lib or lib64.
The only time packages appare to be split between the two folders is
when both the i386 and x86_64 version is installed. From what I know,
SuSE also install x86_64 python programs only in lib64. I therefore
think the correct solution would be to install everything either in
lib64 or in lib.

I agree that our current fix (do nothing) for X86-64 on Fedora Core is
insufficient. I’ve reopened ticket:39 and will kludge our code to
work around the brain damage in FC.

Eric

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs