Ticket #39 (defect)

Opened 2 years ago

Last modified 2 years ago

Sort out python path /lib vs /lib64 on Fedora Core 5 on x86-64

Status: closed (fixed)

Reported by: eb Assigned to: jcorgan
Priority: normal Milestone: release-3.0.3
Component: build Version: 3.0svn
Keywords: Cc:

We need to determine the "right" way to handle python's script path vs python's exec path when running on x86-64 on FC5. By default, imports of swig generated modules fail to locate the .so associated with the wrapper.

Chuck Swiger and David Reed both have FC5 running on X86-64. The problem doesn't show up on SuSE 9.3 Pro. It puts everything in lib64.

Questions: what's the right behavior? What's the "right" thing to put in PYTHONPATH for stuff under /usr/local? How does FC5 handle it now?

We could fix this by ensuring that we install our SWIG generated .py and .so in the same directory, but that still begs the question of what to use for PYTHONPATH.

Change History

08/17/06 09:27:17: Modified by eb

  • status changed from new to assigned.

09/15/06 20:18:15: Modified by eb

  • status changed from assigned to closed.
  • resolution set to wontfix.

This isn't our problem. It's a Fedora Core "feature". The work-around is to add both the lib64 and lib site-packages directories to PYTHONPATH. See comment in source:gnuradio/trunk/README

09/15/06 20:39:40: Modified by eb

Date: Fri, 15 Sep 2006 12:48:51 -0700
From: Eric Blossom <eb@comsec.com>
Subject: [Discuss-gnuradio] X86_64 questions
To: discuss-gnuradio@gnu.org

Thanks to all of you who have sent me the output of the script.
I've got enough for now ;)

Here's the summary:

FC4 and FC5 are internally inconsistent (no data on FC6).

They put the system supplied stuff, both the pure python and the .so's,
under /usr/lib64/python<VER>

However, they have python configured to report that third party stuff
should be split between .../lib and .../lib64.

This leads to mischief and complaints that XYZ is broken.  We
currently believe what python says, and thus split the installation
between lib and lib64.

I see a couple of ways to work around this:

(1) require that FC4, FC5 (and probably FC6) users
be required to include {prefix}/lib64/python<VER>/site-packages AND
{prefix}/lib/python<VER>/site-packages in their PYTHONPATH

(2) kludge our configure code so that if python indicates that
scripts go in lib and .so's go in lib64, we put them all in lib64.


Any comments or suggestions WRT these or other options?

I loved seeing the "purist X86_64" systems -- the ones with no 32-bit code ;)

Eric

09/17/06 20:26:43: Modified by jcorgan

  • priority changed from minor to normal.

01/06/07 20:08:48: Modified by eb

  • status changed from closed to reopened.
  • version changed from 2.8svn to 3.0svn.
  • resolution deleted.
  • milestone changed from release-3.0 to release-3.0.3.

The existing WONTFIX resolution isn't working well enough. It's still generating problems for people. I'm reopening this and will put together an evil kludge that makes the problem go away.

02/21/07 10:08:04: Modified by jcorgan

  • milestone changed from release-3.0.3 to to-be-decided.

02/21/07 11:38:55: Modified by jcorgan

  • owner changed from eb to jcorgan.
  • status changed from reopened to new.
  • milestone changed from to-be-decided to release-3.0.3.

02/25/07 14:36:53: Modified by jcorgan

  • status changed from new to closed.
  • resolution set to fixed.

This is fixed in r4628 on trunk. The gr_python.m4 configuration was updated so that if the machine has /etc/redhat-release, and has lib64 in its $pyexecdir variable, then use that also for the $pythondir variable. NOTE: This will required affected users to manually set PYTHONPATH to $prefix/lib64/python2.4/site-packages (of course, using the correct version number for Python).