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?

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.

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>
> _______________________________________