Christopher Taylor schrieb:
>> The Linux distributions already provide Python binaries (I believe
>> Redhat does, too). You could study what they do to achieve that.
>
> Yes, this is true ... but they do not package the most up-to-date
> version .. which I need.
Sure. However, I still think they
> Ok. One solution might be to remove the libdir option, then. Python
> attempts to be "movable", i.e. the libraries are found relative to
> the executable (via dirname(sys.executable)+"../lib/..."). If
> libdir is supported, this approach must be given up - or libdir must
> be given up.
Well, hon
Christopher Taylor schrieb:
> I disagree. From what I see, the error, as far as python is
> considered, is not being able to specify the location where libs are
> put, despite the fact that the --LIBDIR= option is listed. It just
> happens to manifest itself in AMD64/EM64T Linux, specifically RH
> I personally think this is a bug in AMD64-Linux. Libraries should
> be stored in /usr/lib, binaries in /usr/bin, etc. If they need
> simultaneous installation of 32-bit binaries for compatibility,
> they should store them in architecture-specific directories.
I disagree. From what I see, the err
Christopher Taylor schrieb:
>> Ah, I see. The reason is pretty simple: Makefile.pre.in has
>>
>> LIBDIR= $(exec_prefix)/lib
>>
>> so it seems that LIBDIR isn't configurable.
>
> So you would agree that this is a bug?
I personally think this is a bug in AMD64-Linux. Libraries should
be s
> Ah, I see. The reason is pretty simple: Makefile.pre.in has
>
> LIBDIR= $(exec_prefix)/lib
>
> so it seems that LIBDIR isn't configurable.
So you would agree that this is a bug? I'll post on Python-Dev for
further advice. I'd like to fix this for the x86_64 community.
> You will have
Christopher Taylor schrieb:
> Also, I've fooled around with passing --libdir=/usr/lib64 to the
> configure script and for whatever reason, the Makefile isn't correctly
> written. It always ends up copying the lib files to /usr/lib.
Ah, I see. The reason is pretty simple: Makefile.pre.in has
LIB
Ok, so if I need to build the 32bit binaries, I just need to make sure
I pass the right argument through to the compiler then? (I'm trying
to build 32 bit and 64 bit binaries on the same system, but I'll wait
untill I get just the 64bit stuff built first before I tackle that)
Also, I've fooled a
Christopher Taylor schrieb:
> I had /usr/lib64/python2.3 included and that's why it was breaking. I
> took it out and it works fine now. Unfortunately, it still puts the
> lib files in /usr/lib instead of /usr/lib64. I'm assuming all I need
> to do is set libdir accordingly and the files will ge
PYTHONPATH was the problem.
I had /usr/lib64/python2.3 included and that's why it was breaking. I
took it out and it works fine now. Unfortunately, it still puts the
lib files in /usr/lib instead of /usr/lib64. I'm assuming all I need
to do is set libdir accordingly and the files will get put i
Christopher Taylor schrieb:
> This basically means to me that Python2.4 is loading gloab.py from
> /usr/lib64/Python2.3 insead of /usr/lib/Python2.4 (even thought I
> wanted to install the related files in /usr/lib64/Python2.4)
>
> Can someome please help!
Can you please report what sys.path is?
Christopher Taylor wrote:
> RHEL comes with Python2.3 installed. A program I need to install
> requires Python2.4
ActivePython has a 2.4 build for Linux/x86_64:
http://www.activestate.com/Products/ActivePython/
Cheers,
Trent
--
Trent Mick
[EMAIL PROTECTED]
--
http://mail.python.org/mailman/l
12 matches
Mail list logo
