I tryto build python 2.4 with:
./configure --enable-unicode=4 --prefix=/usr
--exec-prefix=/usr

Attached is the config.log file

Logged In: YES 
user_id=1624982

Ok, so when you add a file, it automatically submits ....

Well ... like I was saying..

./configure --enable-unicode=ucs4 --prefix=/usr
--exec-prefix=/usr
make
make altinstall

please see attached config.log for the configuration of python. 

I then go to make mod_python with
./configure --with-python=/usr/bin/python2.4
make

and then I get the errors listed in MP_compile_error.txt
please also see MP_config.log

It seems the linker is having a problem with libpython2.4.a
 making it look like it wasn't compiled properly.

Logged In: YES 
user_id=849994

The unicode build option should be "--enable-unicode=ucs4".
Can you retry with that option?

Logged In: YES 
user_id=1624982

wait, I didn't mean to change the status, sory about that.

Logged In: YES 
user_id=849994

actually, this is okay, the "pending" status is
automatically set to "open" again when the OP posts an answer.

I can't read anything out of that error log, however,
perhaps Martin can.

Logged In: YES 
user_id=1624982

I think the important part of the mod_python compile error
is the last part where the linker fails to link in
libpython2.4.a   ... that's why I think it's an error with
the configure file for python.  It says that libpython2.4.a
should be compiled with position-independant-code.  If I
remember correctly, any static library needs to be PIC for a
x86_64 machine ... that's why it seems like an error for python.

/usr/bin/ld:
/usr/lib/python2.4/config/libpython2.4.a(abstract.o):
relocation R_X86_64_32 against `a local symbol' can not be
used when making a shared object; recompile with -fPIC
/usr/lib/python2.4/config/libpython2.4.a: could not read
symbols: Bad value
collect2: ld returned 1 exit status
apxs:Error: Command failed with rc=65536

Logged In: YES 
user_id=21627

It's actually not a bug in the Python configure, but a
limitation of AMD64 (or, rather, the linker/dynamic loader
toolchain).

It complains that some object file of Python wasn't compiled
with -fPIC (position-independent code). This is a problem
only if
a) you are linking a static library into a shared one
(mod_python, in this case), and
b) the object files in the static library weren't compiled
with -fPIC, and
c) the system doesn't support position-dependent code in a
shared library

As you may have guessed by now, it is really c) which I
blame. On all other modern systems, linking non-PIC objects
into a shared library is supported (albeit sometimes with a
performance loss on startup).

So your options are
a) don't build a static libpython, instead, build Python
with --enable-shared. This will give you libpython24.so
which can then be linked "into" mod_python
b) manually add -fPIC to the list of compiler options when
building Python, by editing the Makefile after configure has run
c) find a way to overcome the platform limitation. E.g. on
Solaris, the linker supports an impure-text option which
instructs it to accept relocations in a shared library.

You might wish that the Python build process supported
option b), i.e. automatically adds -fPIC on Linux/AMD64.
IMO, this would be a bad choice, since -fPIC itself usually
causes a performance loss, and isn't needed when we link
libpython24.a into the interpreter (which is an executable,
not a shared library).

Therefore, I'll close this as "won't fix", and recommend to
go with solution a).

Logged In: YES 
user_id=1624982

OK, thanx for the time/tutelage.

I'll ask you off line about some other difficulties I'm
having with 64 & 32-bit python library locations.