Configure script does not work for RHEL 4 x86_64

[spotvt01]

BPO	1580726
Nosy	@loewis, @birkenfeld
Files	config.log: Config Log mp_config.log: mp_config.log MP_compile_error.txt: mp_compile_error.txt

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2006-10-23.15:00:27.000>
created_at = <Date 2006-10-19.18:38:12.000>
labels = ['expert-installation']
title = 'Configure script does not work for RHEL 4 x86_64'
updated_at = <Date 2006-10-23.15:00:27.000>
user = 'https://bugs.python.org/spotvt01'

bugs.python.org fields:

activity = <Date 2006-10-23.15:00:27.000>
actor = 'spotvt01'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['Installation']
creation = <Date 2006-10-19.18:38:12.000>
creator = 'spotvt01'
dependencies = []
files = ['2186', '2187', '2188']
hgrepos = []
issue_num = 1580726
keywords = []
message_count = 8.0
messages = ['30314', '30315', '30316', '30317', '30318', '30319', '30320', '30321']
nosy_count = 3.0
nosy_names = ['loewis', 'georg.brandl', 'spotvt01']
pr_nums = []
priority = 'normal'
resolution = 'wont fix'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue1580726'
versions = []

[spotvt01]

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

Attached is the config.log file

[spotvt01]

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.

[birkenfeld]

Logged In: YES
user_id=849994

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

[spotvt01]

Logged In: YES
user_id=1624982

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

[birkenfeld]

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.

[spotvt01]

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

[loewis]

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).

[spotvt01]

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.