Installing Python 2.4 on CentOS 8 fails with segmentation fault - python

I am having problems installing Python 2.4.6 on CentOS 8.
I need the old Python 2.4.6 because I have some apps running which require Python 2.4.
I downloaded the Python 2.4.6.tgz package, extracted it and run "./configure" which works.
When I try to run "make", I see a lot of warnings and at the end the following error message is shown:
gcc -pthread -Xlinker -export-dynamic -o python \
Modules/python.o \
libpython2.4.a -lpthread -ldl -lutil -lm
libpython2.4.a(posixmodule.o): In function `posix_tmpnam':
/usr/local/src/Python-2.4.6/./Modules/posixmodule.c:6240: warning: the use of `tmpnam_r' is dangerous, better use `mkstemp'
libpython2.4.a(posixmodule.o): In function `posix_tempnam':
/usr/local/src/Python-2.4.6/./Modules/posixmodule.c:6195: warning: the use of `tempnam' is dangerous, better use `mkstemp'
case $MAKEFLAGS in \
*-s*) CC='gcc -pthread' LDSHARED='gcc -pthread -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py -q build;; \
*) CC='gcc -pthread' LDSHARED='gcc -pthread -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py build;; \
esac
/bin/sh: line 1: 5296 Segmentation fault (core dumped) CC='gcc -pthread' LDSHARED='gcc -pthread -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py build
make: *** [Makefile:342: sharedmods] Error 139
Any idea, what might be wrong here? If required, I can post the whole output after I run "make" (which is quite long).
Thanks a lot in advance.

I would recommend to go a different route than installing Python 2.4 on your OS. That thing is ancient, it can only bring security issues.
So if your apps don't work with even Python 2.7, perhaps you have better luck with running Python 2.4 in a Docker. See e.g. https://github.com/pantuza/docker-python-2.4.3 for a docker image with Python 2.4 and https://www.docker.com/get-started for an introduction on docker.
And probably the next step should be porting those apps to Python 3, such that you can get rid of that ancient Python version for good.

Related

PyCharm/Cython cross-compile on Windows? [duplicate]

I have simple python + cython project (hello world example from http://docs.cython.org/src/tutorial/cython_tutorial.html) on my ubuntu 16 x86_64. I can build this project with cython for x86_64.
How can I build the project for armv7 version of ubuntu 15 without using real armv7 board/cpu?
I have arm-linux-gnueabihf-gcc (http://packages.ubuntu.com/xenial/devel/gcc-arm-linux-gnueabihf) and it can compile simple C programs for armv7. How can I change settings of cython to use cross compiler for building shared objects for arm?
Architecture dependent libraries and headers files are needed for cross compiling.
When testing if python3.5-dev package and others could be installed after dpkg --add-architecture armhf and apt-get update (after some modification to sources.list), the result was basically.
python3.5-dev:armhf : Depends: python3.5:armhf (= 3.5.1-10) but it is not going to be installed
apt-get install python3.5:armhf is something that doesn't work, see
The existing proposals allow for the co-installation of libraries and
headers for different architectures, but not (yet) binaries.
One possible solution that does not require "full" virtual machine is provided by QEMU and chroot. A suitable directory for chroot can be created by debootstrap command. After creation, schroot can give access to that environment.
Substitute <DIRECTORY> and <USER> in the following commands:
apt-get install -y debootstrap qemu-user-static binfmt-support schroot
debootstrap --arch=armhf --foreign --include=gcc,g++,python3.5-dev xenial <DIRECTORY>
cp /usr/bin/qemu-arm-static <DIRECTORY>/usr/bin
chroot <DIRECTORY>
/debootstrap/debootstrap --second-stage
echo "deb http://ports.ubuntu.com/ubuntu-ports xenial universe" >> /etc/apt/sources.list
echo "deb http://ports.ubuntu.com/ubuntu-ports xenial multiverse" >> /etc/apt/sources.list
apt-get update
apt-get install -y cython cython3
exit
cat <<END > /etc/schroot/chroot.d/xenial-armhf
[xenial-armhf]
description=Ubuntu xenial armhf
type=directory
directory=/home/xenial-armhf
groups=sbuild,root
root-groups=sbuild,root
users=root,<USER>
END
The environment should be accessible by
schroot -c chroot:xenial-armhf
and for root user session (the user must be in a group listed in root-groups) ,
schroot -c chroot:xenial-armhf -u root
After this, it is also possible to cross compile a cython module:
hello.pyx:
print("hello world")
compiling (python3.5-config --cflags and python3.5-config --libs in chroot for options, note -fPIC):
cython hello.pyx
arm-linux-gnueabihf-gcc --sysroot <DIRECTORY> -I/usr/include/python3.5m -I/usr/include/python3.5m -Wno-unused-result -Wsign-compare -g -fstack-protector-strong -Wformat -Werror=format-security -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -c hello.c
arm-linux-gnueabihf-gcc --shared --sysroot <DIRECTORY> -lpython3.5m -lpthread -ldl -lutil -lm hello.o -o hello.so
The module can be then tested
schroot -c chroot:xenial-armhf
python3
import hello
Cross compiling cython based python modules may also work. With setup.py
from distutils.core import setup
from distutils.extension import Extension
from Cython.Distutils import build_ext
import os
os.environ['CC'] = 'arm-linux-gnueabihf-gcc'
os.environ['LDSHARED'] = 'arm-linux-gnueabihf-gcc -shared'
sysroot_args=['--sysroot', '/path/to/xenial-armhf']
setup(cmdclass = {'build_ext': build_ext},
ext_modules= [ Extension("hello", ["hello.pyx"],
extra_compile_args=sysroot_args,
extra_link_args=sysroot_args) ])
Building a simple hello world module was possible this way. The file name for the module was wrong, in this case it was hello.cpython-35m-x86_64-linux-gnu.so. After renaming it as hello.so it was possible to import it.

Cython: Compiling and Cannot Find Library Mac OSX 10.12

I am just getting started with Cython and am trying to compile a "Hello World" script. I am trying to use gcc -Os /User/Documents/Python/Test\ Python/helloCopy.c -I/Library/Frameworks/Python.framework/Versions/3.5/include/python3.5m -l, but I don't know what to add after the -l. Other forum pages say to "include -lpython2.7 (or whatever version of Python you're using) on the linker command-line" but that produces ld: library not found for -lpython3.5
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Should I be directing the -l to a particular folder?
I do not know what resource you're using, but this does not say anything about a -l flag. It suggests
cython -a helloCopy.pyx
This creates a yourmod.c file, and the -a switch produces an annotated html file of the source code. Pass the -h flag for a complete list of supported flags.
gcc -shared -pthread -fPIC -fwrapv -O2 -Wall -fno-strict-aliasing -I/usr/include/python2.7 -o helloCopy.so helloCopy.c
(Linux)
On macOS I would try to compile with
gcc -I/usr/bin/python -o helloCopy.so helloCopy.c
to use the standard version of Python.

Fatal error when trying to install PyCrypto on OS X El Capitan

I am trying to install PyCrypto on OS X 10.11.3 (El Capitan). I am using Python 3.5.1. I downloaded the gzip file from https://pypi.python.org/pypi/pycrypto and decompressed it. Then I ran python setup.py build like the instructions said and it appeared to do something, then it produced this output:
/usr/bin/clang -fno-strict-aliasing -fno-common -dynamic -isysroot /Developer/SDKs/MacOSX10.6.sdk -arch i386 -arch x86_64 -fwrapv -Wall -Wstrict-prototypes -std=c99 -O3 -fomit-frame-pointer -Isrc/ -I/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -c src/MD2.c -o build/temp.macosx-10.6-intel-2.7/src/MD2.o
src/MD2.c:30:10: fatal error: 'string.h' file not found
#include <string.h>
^
1 error generated.
error: command '/usr/bin/clang' failed with exit status 1
I tried python3 setup.py build and got some very similar output:
/usr/bin/clang -fno-strict-aliasing -Wsign-compare -Wunreachable-code -fno-common -dynamic -fwrapv -Wall -Wstrict-prototypes -arch i386 -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.6.sdk -std=c99 -O3 -fomit-frame-pointer -Isrc/ -I/Library/Frameworks/Python.framework/Versions/3.5/include/python3.5m -c src/MD2.c -o build/temp.macosx-10.6-intel-3.5/src/MD2.o
src/MD2.c:30:10: fatal error: 'string.h' file not found
#include <string.h>
^
1 error generated.
error: command '/usr/bin/clang' failed with exit status 1
I tried Googling to figure out what to do, but I couldn't find anything useful. How can I install PyCrypto?
EDIT: I also tried several other things like pip install pycrypto and sudo pip3 install pycrypto and they didn't work. #l'L'l helped me get it to work by doing several strange, complex things that I never would have though have myself. They are summarized in the answer below.
Overview:
The manual build you're trying looks like it might be failing because it's referencing the OS X 10.6 SDK, which you likely don't have, and is outdated for the most part. Also, SDKs are now stored in a completely different location than when the 10.6 SDK was in it's prime.
New SDKs location:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/
Old SDKs location:
/Developer/SDKs/
Non-existent / outdated SDK:
Since it appears that when trying to build PyCrypto it's referencing the MacOSX10.6.sdk there are several things to consider:
Why does it reference an outdated SDK
Where is the SDK it's referencing set
What should be done to correct the issue
Unless we audit the source code carefully we might not know exactly where the incorrect flags are set, but we can do our best to work with the information we have. From the error we can see that there are several instances where the 10.6 SDK's name pops up:
/usr/bin/clang -fno-strict-aliasing -fno-common -dynamic -isysroot /Developer/SDKs/MacOSX10.6.sdk -arch i386 -arch x86_64 -fwrapv -Wall -Wstrict-prototypes -std=c99 -O3 -fomit-frame-pointer -Isrc/ -I/Library
Building from source:
/Frameworks/Python.framework/Versions/2.7/include/python2.7 -c src/MD2.c -o build/temp.macosx-10.6-intel-2.7/src/MD2.o
src/MD2.c:30:10: fatal error: 'string.h' file not found
#include <string.h>
^
1 error generated.
error: command '/usr/bin/clang' failed with exit status 1
Analyzing this we can see that the PyCrypto's MD2.c file is trying to be built using the flag -isysroot /Developer/SDKs/MacOSX10.6.sdk. It might be worth trying pip instead:
Installing with pip:
...
fatal error: 'string.h' file not found #include <string.h>
...
Same error; we should probably find out if the <string.h> header even exists on the system — Let's make a quick test C application to find out:
Testing the C headers:
$ echo "#include <string.h>
#include <stdio.h>
int main() { printf(\"TEST\n\"); return 0; }" > t.c
$ clang t.c -o t
$ ./t
TEST
It's apparent the header does exist because the test worked fine. This tells us that the problem is more likely related directly to the 10.6 SDK (which doesn't seem to exist on the system).
Symlinking (non-existing) 10.6 SDK to 10.11 SDK:
Since we haven't determined where the SDK is actually getting set we'll go ahead and try to create symlinks so that any reference of the old 10.6 SDK links to the latest SDK (10.11 at this time):
$ cd /Developer/SDKs
$ sudo ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk MacOSX10.6.sdk
We can verify the symlink by issuing the following command:
$ ls -lat
total 8
drwxr-xr-x 3 root wheel 102 Feb 21 15:54 .
lrwxr-xr-x 1 root wheel 99 Feb 21 15:54 MacOSX10.6.sdk -> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
drwxr-xr-x 3 root wheel 102 Feb 21 15:52 ..
Now that we've successfully created the symlink let's try installing PyCrypto with pip once more:
$ sudo pip install pycrypto
Collecting pycrypto
Downloading pycrypto-2.6.1.tar.gz (446kB)
100% |████████████████████████████████| 446kB 1.2GB/s
Installing collected packages: pycrypto
Running setup.py install for pycrypto ... done
Successfully installed pycrypto-2.6.1
No errors! It looks like our problem is solved! Well, almost...
We still need to figure out what is responsible for setting the wrong (10.6) SDK during builds. Let's use the xcrun tool to see what the defaults are set at:
$ xcrun --show-sdk-version
10.11
The system default SDK is set to 10.11, so it must be get set incorrectly to 10.6 by Python, PyCrypto, or some other anomaly we might not have considered.
UPDATE:
After doing some recon it was discovered that Python 3 appears to be built with the OS X 10.6 SDK. In addition it's also setting the SDK to 10.6 and setting the (outdated) path in numerous places throughout the Python_Framework. There are so many references I won't bother listing them all, although here's an example:
Python_Framework Folder/Versions/3.5/lib/python3.5/config-3.5m/Makefile:79:CONFIGURE_CFLAGS= -arch i386 -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.6.sdk
I can only assume the developers were trying to be as backward compatible as possible, however, it's unfortunately breaking forward compatibility in the process.
Notes:
Installing Python packages with pip can make life much easier in a lot of ways (package management, updating, uninstalling, etc.). For example installing PyCrypto should just be a matter of issuing the command:
$ sudo pip install pycrypto
If you have multiple Python's you can use the version number to install for that Python accordingly:
$ sudo pip3.5 install pycrypto
↳ https://pip.pypa.io/en/stable/installing/
I had what might be a related issue on OSX El Capitan when I would run pip install pycrypto. I was seeing RuntimeError: autoconf error. All I had to do was run sudo xcodebuild -license and type agree after reviewing the licence agreement. Afterward I was able to use pip to install pycrypto.

Fatal Python error when using SWIG under OSX

I have troubles using a Python interface generated with SWIG (I have OSX 10.11.12). After compiling and linking everything together as such:
swig -python erk_integrator.i
gcc -c -fPIC -O3 model.c auxiliary_functions.c timing_functions.c
gcc -c -fPIC -O3 erk_integrator.c erk_integrator_wrap.c -I. -I/usr/local/include/python2.7
gcc -lpython -dynamiclib model.o erk_integrator.o erk_integrator_wrap.o auxiliary_functions.o timing_functions.o -o _erk_integrator.so
I try a test script, but Python throws a fatal error:
/usr/local/bin/python test_erk.py
Fatal Python error: PyThreadState_Get: no current thread
Abort trap: 6
But when I run
/System/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7 test_erk.py
everything works as it should. However, I need to use /usr/local/bin/python (from Homebrew) instead of the system Python.
I think something goes wrong in the linking step. Many thanks for helping!
This blog post helped me solve it: blog.tim-smith.us/2015/09/python-extension-modules-os-x
It turns out on OSX you need
-undefined dynamic_lookup
instead of
-lpython

Python 2.7.6 error when building from source: gcc.orig: directory": No such file or directory

I've been provisioned a very bare-bones RHEL 4.4 at work; e.g., it didn't have java or gcc installed.
I have followed this guide to install python 2.7.6 on another VM (RHEM 4.6) successfully. However on this new vm, I cannot make without getting this error:
gcc -pthread -c -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -DPy_BUILD_CORE \
-DSVNVERSION="\"`LC_ALL=C echo Unversioned directory`\"" \
-DHGVERSION="\"`LC_ALL=C `\"" \
-DHGTAG="\"`LC_ALL=C `\"" \
-DHGBRANCH="\"`LC_ALL=C `\"" \
-o Modules/getbuildinfo.o ./Modules/getbuildinfo.c
gcc.orig: directory": No such file or directory
<command-line>: warning: missing terminating " character
./Modules/getbuildinfo.c: In function â_Py_svnversionâ:
./Modules/getbuildinfo.c:63: error: missing terminating " character
./Modules/getbuildinfo.c:63: error: expected expression before â;â token
make: *** [Modules/getbuildinfo.o] Error 1
I tried what was suggested in this unrelated bug report:
SVNVERSION="Unversioned directory"
./configure
make
but received the same error.
I saw this question on super user, which suggests to check the output of the svnversion command in the Modules directory, but I don't have svn or svnversion on this machine. It also suggests to edit the function _PY_svnversion in Modules/getbuildinfo.c, which I did but received the same error.
Any ideas?
Ok I found the answer in my case:
issue configure which will create a new Makefile
edit the Makefile with vi.
search for SVNVERSION and set it to
SVNVERSION= ""
make will then work.

Categories

Resources