Latest GIT on OpenSuse 11.4 x64 - PYTHONPATH

Hi all,

I have been experimenting with gnuradio about 2y ago and everything went
just
fine.

Now I’m trying for about 5 days to get it to work again.
Configure, check, compile and install go through fine.
Just whatever I try, I can’t get grc running. I always get the message
about
checking PYTHONPATH or LD_LIBRARY_PATH.

I installed gnuradio to /usr/local because one lib insists to be there.
When
changing the prefix to /usr, building fails.

OS11.4 has python at /usr/lib/python2.6 and /usr/lib/python2.7 as well
as
/usr/lib64/python2.6 and /usr/lib64/python2.7

I tried setting PYTHONPATH to /usr/local/lib/python2.6/site-packages,
/usr/local/lib/python2.7/site-packages,/usr/local/lib64/python2.6/site-
packages and /usr/local/lib64/python2.7/site-packages.

No success at all. python -c “from gnuradio import gr” always fails.

Can anybody give me some hints on this?

–Stefan

On Thu, 2011-04-21 at 05:05 +0300, Stefan Gofferje wrote:

I installed gnuradio to /usr/local because one lib insists to be there. When

Can anybody give me some hints on this?

Try “locate gnuradio/init.py”.

–n

On Thu, 2011-04-21 at 05:05 +0300, Stefan Gofferje wrote:

Try “locate gnuradio/init.py”.

–n

Another issue is that if you’d installed Gnu Radio from a
distribution-packaged instance, the
dynamic linker will find its shared-libraries first, which can
cause incompatibilities between
the python code (that was presumably found through the GIT-installed
stuff), and the
probably-obsolete-the-moment-they-were-hatched “packaged” libraries.

It’s instructive to (assuming your PYTHONPATH is set correctly):

python

from gnuradio import gr

That will either barf or not. The details of that barf are
instructive in intuiting what’s wrong.


Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

On Thursday 21 April 2011, Marcus D. Leech wrote:

python

from gnuradio import gr

[email protected]:~> python -c “from gnuradio import gr”
Traceback (most recent call last):
File “”, line 1, in
File “/usr/local/lib/python2.7/site-packages/gnuradio/gr/init.py”,
line
43, in
from gnuradio_core import *
File
“/usr/local/lib/python2.7/site-packages/gnuradio/gr/gnuradio_core.py”,
line 23, in
from gnuradio_core_runtime import *
File “/usr/local/lib/python2.7/site-
packages/gnuradio/gr/gnuradio_core_runtime.py”, line 24, in
_gnuradio_core_runtime = swig_import_helper()
File “/usr/local/lib/python2.7/site-
packages/gnuradio/gr/gnuradio_core_runtime.py”, line 16, in
swig_import_helper
import _gnuradio_core_runtime
ImportError: No module named _gnuradio_core_runtime

Hi,

On Thursday 21 April 2011, Marcus D. Leech wrote:

Normally, the installer places the relevant .so files (the ones that
Python will dynamically load
into itself) right next to the relevant Python files.

Does your PYTHONPATH include both /usr/local/lib/python2.7/site-packages
and /usr/local/lib64/python2.7/site-packages?

I still didn’t get grc running. PYTHONPATH includes both of the
directories.
Could it be a requirement that all the files are in the same dir? Maybe
some
absolute or half-absolute path settings in one of the python modules?

-S

On 04/20/2011 10:56 PM, Stefan Gofferje wrote:

[email protected]:~> ll /usr/local/lib/python2.7/site-
packages/gnuradio/gr/gnuradio_core_runtime
-rw-r–r-- 1 root root 68910 Apr 21 05:09 /usr/local/lib/python2.7/site-
packages/gnuradio/gr/gnuradio_core_runtime.py
-rw-r–r-- 1 root root 113536 Apr 21 05:09 /usr/local/lib/python2.7/site-
packages/gnuradio/gr/gnuradio_core_runtime.pyc
-rw-r–r-- 1 root root 113536 Apr 21 05:09 /usr/local/lib/python2.7/site-
packages/gnuradio/gr/gnuradio_core_runtime.pyo

OK, so there’s also supposed to be a .so and .la file along with
those, so something bad happened
either during generation of those library files during the build, or
during the install.

For comparison, here’s what mine looks like:

rwxr-xr-x. 1 root root 1199 2011-04-07 20:39
_gnuradio_core_runtime.la
-rw-r–r--. 1 root root 68910 2011-04-07 20:39
gnuradio_core_runtime.py
-rw-r–r--. 1 root root 113508 2011-04-07 20:39
gnuradio_core_runtime.pyc
-rw-r–r--. 1 root root 113508 2011-04-07 20:39
gnuradio_core_runtime.pyo
-rwxr-xr-x. 1 root root 1848947 2011-04-07 20:39
_gnuradio_core_runtime.so


Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

Unfortunately, the Gnuradio “make install” Installer
is a bit buggy. It distributes python libs between
the lib64 and lib folders. Python cannot handle this chaos,
even with both directories in PYTHONPATH.

I solved it by creating a symlink before installing:

ln -s /usr/local/lib64/python2.7/ /usr/local/lib/python2.7

Apparently, Gnuradio is the only app that wrote to
/usr/local/lib/python2.7,
because this directory didn’t exist before (pure 64 Bit operating
system).

After symlinking, the “make install” effectively writes all into
a single destination and Python finds all dependencies.

I never understood, why this Linux introduced the lib64 folders.
Why not keeping the 64 Bit code in the lib standard location
and put all legacy 32 bit code in lib32 folders?
Do other Linux distributions handle this in a different way?

On 04/27/2011 01:19 PM, Moeller wrote:

because this directory didn’t exist before (pure 64 Bit operating system).

After symlinking, the “make install” effectively writes all into
a single destination and Python finds all dependencies.

I never understood, why this Linux introduced the lib64 folders.
Why not keeping the 64 Bit code in the lib standard location
and put all legacy 32 bit code in lib32 folders?
Do other Linux distributions handle this in a different way?

Other Redhat family distros seem to do it the same way opensuse does.

Ubantu on 64 bit machines has a lib32 and lib, lib64 is just a symbolic
link to lib. I think that makes tons of sense:

ls -al /usr/
total 272
drwxr-xr-x 11 root root 4096 2011-01-18 11:34 .
drwxr-xr-x 24 root root 4096 2011-03-19 10:26 …
drwxr-xr-x 2 root root 69632 2011-04-15 09:00 bin
drwxr-xr-x 2 root root 4096 2011-04-01 23:59 games
drwxr-xr-x 75 root root 20480 2011-04-08 10:44 include
drwxr-xr-x 246 root root 102400 2011-04-15 09:00 lib
drwxr-xr-x 41 root root 36864 2011-01-26 22:44 lib32
lrwxrwxrwx 1 root root 3 2010-11-25 20:56 lib64 -> lib
drwxr-xr-x 9 jblum root 4096 2011-01-21 15:18 local
drwxr-xr-x 2 root root 12288 2011-04-11 11:02 sbin
drwxr-xr-x 362 root root 12288 2011-04-08 10:44 share
drwxrwsr-x 12 root src 4096 2011-03-19 10:25 src

-Josh

Apparently, Gnuradio is the only app that wrote to /usr/local/lib/python2.7,
because this directory didn’t exist before (pure 64 Bit operating system).

After symlinking, the “make install” effectively writes all into
a single destination and Python finds all dependencies.

I never understood, why this Linux introduced the lib64 folders.
Why not keeping the 64 Bit code in the lib standard location
and put all legacy 32 bit code in lib32 folders?
Do
Fedora also uses the /usr/local/lib64 thing for 64-bit platforms, but
the Gnu Radio installer
works just fine on Fedora x86_64 platforms [at least F12 through F14,
which I’ve tested
over the last year or two].

There must be something in the setup of a OpenSuse 64-bit system that
confuses “configure”, since
that’s where, ultimately, the makefiles get their information from.

Or, perhaps “Fedora” and “x86_64” are special-cased in configure, and a
similar special case doesn’t
exist for OpenSuse?

Regardless, I suspect the answer lies in either “bootstrap” or
“configure” getting slightly confused on
an OpenSuse system.


Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

Hi,

Just a side note: In my system (OpenSuse11.2 x86_64) I had to slightly
modify the symlink to

ln -s /usr/local/lib64/python2.7 /usr/local/lib/

best regards,
Pedro Ignacio Martos

----- Original Message ----- >

On Wednesday 27 April 2011, Moeller wrote:

I solved it by creating a symlink before installing:

ln -s /usr/local/lib64/python2.7/ /usr/local/lib/python2.7

I confirm that this solves the issue!
After creating the symlink and re-installing, grc runs fine, as does the
rest.

Thanks a lot!

-S

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