classification
Title: Python-2.7.16 fails to build with --enable-shared
Type: behavior Stage: resolved
Components: Build Versions: Python 2.7
process
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: Nosy List: lopez@ucar.edu, zach.ware
Priority: normal Keywords:

Created on 2019-07-07 02:43 by lopez@ucar.edu, last changed 2020-04-26 18:12 by lopez@ucar.edu. This issue is now closed.

Messages (3)
msg347461 - (view) Author: Willie Lopez (lopez@ucar.edu) Date: 2019-07-07 02:43
When building Python-2.7.16 on CentOS-7.4, building with --enable-shared through ./configure will cause Python to fail its build without errors and will install python-2.7.5, the wrong version. If Python is built without --enable-shared, other compilations that need Python will fail with the cryptic error in the following. Recompiling the app such as Apache will continue fail even when explicitly defining -fPIC in CFLAGS. However, trying to build Python with the shared flag appears to succeed, but in fact it fails and installs Python-2.7.5, the wrong version. 

/bin/ld: /usr/local/lib/libz.a(crc32.o): relocation R_X86_64_32 against .rodata' can not be used when making a shared object; recompile with -fPIC 

I have tried to build manually build Python with the following:
./buildconf (with and without running buildconf)
CFLAGS='-fPIC -g -O2' ./configure --prefix=$HOME/tools 
make
make altinstall %{buildroot}%{prefix} 

What am I missing? What am I doing wrong in the build?
msg367310 - (view) Author: Zachary Ware (zach.ware) * (Python committer) Date: 2020-04-26 16:25
Hi Willie,

Sorry this never got attention before 2.7 reached end-of-life, but as that has now happened, I'm closing the issue.

That said, I suspect your issue here was with library search path; it wasn't actually 2.7.5 that was installed by the install of 2.7.16, but rather it was the system's 2.7.5 library that was loaded instead of the installation's 2.7.16 due to the latter's directory being either not on the search path or after the system's Python library location.  I'm not sure if there's really a good way to have two separate patch versions of Python, both with shared libraries rather than static, without winding up with some confusion about which library should be loaded by which application.
msg367324 - (view) Author: Willie Lopez (lopez@ucar.edu) Date: 2020-04-26 18:12
Thank you anyway. I was able to finally resolve the issue, which did turn out to be the environment variable PYTHONPATH. When compiling python from source, that variable must be empty (not null). After emptying the string value the compilation worked. 

This probably has to do more with having two versions of python, the system and our application side. The env variable is always set on our dev and app servers. Not a good practice when compiling from source.

Thanks!

Willie Lopez
———————————-
Willie.lopez@yahoo.com
970.481.8246

> On Apr 26, 2020, at 10:25 AM, Zachary Ware <report@bugs.python.org> wrote:
> 
> 
> Zachary Ware <zachary.ware@gmail.com> added the comment:
> 
> Hi Willie,
> 
> Sorry this never got attention before 2.7 reached end-of-life, but as that has now happened, I'm closing the issue.
> 
> That said, I suspect your issue here was with library search path; it wasn't actually 2.7.5 that was installed by the install of 2.7.16, but rather it was the system's 2.7.5 library that was loaded instead of the installation's 2.7.16 due to the latter's directory being either not on the search path or after the system's Python library location.  I'm not sure if there's really a good way to have two separate patch versions of Python, both with shared libraries rather than static, without winding up with some confusion about which library should be loaded by which application.
> 
> ----------
> nosy: +zach.ware
> resolution:  -> out of date
> stage:  -> resolved
> status: open -> closed
> 
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue37518>
> _______________________________________
History
Date User Action Args
2020-04-26 18:12:08lopez@ucar.edusetmessages: + msg367324
2020-04-26 16:25:30zach.waresetstatus: open -> closed

nosy: + zach.ware
messages: + msg367310

resolution: out of date
stage: resolved
2019-07-07 02:43:59lopez@ucar.educreate