We're using this configure script with an option we spotted in the configure help menu:
./configure --with-universal-archs=32-bit --prefix="$HOME/python"
make
make install
But when all the dust is settled and we check out what it gives us:
✔python-3.1.1⤿ file ~/python/bin/python3
python/bin/python3: Mach-O 64-bit executable x86_64
How do we compile it so we're given a 32-bit python? We're looking to use the uno module provided by OpenOffice, which requires 32-bit python.
There's no need to build your own. Use the Python 3.1.1 OS X installer from python.org. It's 32-bit only and will work just fine on OS X 10.4 through 10.6. If you need to install any packages with C extension modules on 10.6, you'll need to install the optional 10.4 SDK from the the Snow Leopard Xcode mpkg and you'll need to tell Distutils to use GCC 4.0:
$ export CC=/usr/bin/gcc-4.0
I'd try CFLAGS=-m32 LDFLAGS=-m32 although I don't have the requisite hardware to test that it works.
I'm not familiar with the --with-universal-archs option -- must be specific to OS X?
Related
I am using python in the MSYS2 environment. The MSYS2 has its own built MINGW python version. Also I can install the official python from the www.python.org.
Here is the problem: If I want to write a python code need to know the python version is MINGW or the official one, how can I do it?
Here are some ways I can image.
Use the "sys.prefix" object. It tells the installation directory. the MSYS2 usually installed in the directory X:\msys2\.... and the official one install in the X:\Python27\ as default. But users may change the installation directory. So this is not a good way.
Use the "sys.version" object can get the version strings show with the compiler name. It shows the MINGW python compiled by GCC, the official one compiled by MSC. But there may have some possibility that there is an other version's python also built by GCC or MSC.
Is there any more elegant way can do this?
Mingw python3 build patched official sysconfig.get_platform() function so it returns "mingw" and can be used for distinguishing from official python builds.
https://github.com/Alexpux/MINGW-packages/blob/abd06ca92d876b9db05dd65f27d71c4ebe2673a9/mingw-w64-python2/0410-MINGW-build-extensions-with-GCC.patch#L54
Another option is to check if GCC is in sys.version.
For example:
import sys
MSYS2 = ("GCC" in sys.version)
print(MSYS2)
> True
This works because the sys.version information has the type of compiler used, and MinGW uses GCC.
python -c "import sys; print(sys.version)"
3.7.4 (default, Aug 15 2019, 18:17:27) [GCC 9.2.0 64 bit (AMD64)]
sys.platform gives msys when in msys-Python.
I'm trying to install numpy 1.7 via an RPM on an older Linux machine with Python 2.4. The numpy release notes and the RPM page say it is supposed to be compatible with 2.4 (or <= 2.7), but when I try to install it on the machine with the command
rpm -i /tmp/python-numpy-1.7.0-2.1.i586.rpm
I get a number of missing dependency notes, including:
libc.so.6(GLIBC_2.11) is needed by python-numpy-1.7.0-2.1.i586
libc.so.6(GLIBC_2.4) is needed by python-numpy-1.7.0-2.1.i586
liblapack.so.3 is needed by python-numpy-1.7.0-2.1.i586
libpython2.7.so.1.0 is needed by python-numpy-1.7.0-2.1.i586
python >= 2.7 is needed by python-numpy-1.7.0-2.1.i586
python = 2.7 is needed by python-numpy-1.7.0-2.1.i586
python(abi) = 2.7 is needed by python-numpy-1.7.0-2.1.i586
rpmlib(PayloadIsLzma) <= 4.4.6-1 is needed by python-numpy-1.7.0-2.1.i586
So now at least Python 2.7 is needed, rather than up to 2.7. Is this a real discrepancy or am I using rpm incorrectly? I'm used to higher-level Linux package managers that report dependencies correctly and install them automatically, so I'm unsure how to proceed here.
Are you sure your distribution does not provide numpy already? It looks like numpy is part of epel.
If for some reason you are unwilling to use the version in the distribution, you're likely going to have to build the RPM yourself. I was able to build 1.7.1 on CentOS 5.7 like so:
sudo yum install rpm-build gcc python-devel
wget 'https://pypi.python.org/packages/source/n/numpy/numpy-1.7.1.tar.gz'
tar -xf numpy-1.7.1.tar.gz
cd numpy-1.7.1/
python setup.py bdist_rpm
sudo yum localinstall dist/numpy-1.7.1-1.i386.rpm
the generated RPM (in ./dist) should be useable without rebuilding on all of the machines with similar hardware and OS.
If all the machines have identical versions of Python, glibc, etc., then it would probably be easier to get the numpy source and build it yourself, assuming you have gcc (and perhaps gfortran) installed, along with dependencies like BLAS and LAPACK. Once it's installed on one machine, you can copy the numpy folder (and any .egg file) from /usr/lib/python2.4/site-packages (or whichever directory) and distribute that around the world. Make sure to create static libraries when you build so you don't need all the dependencies everywhere.
I'd also get numpy 1.7.1, as it fixes some issues with 1.7.0.
When I try to install numpy over a python.org python2.6 installation, I get these errors on my OS X terminal.
sh: gcc-4.2: command not found
And this causes failure. I noticed a pastebin (http://pastebin.com/hieSKe3A) already on this issue but I'm unable to find an answer online that works for Snow Leopard (there seem to be a lot of answers for Lion).
I noticed numpy requires the python.org python2.6 installation. I'm trying to do that. Btw, if there is a way for me to prevent the installer of the numpy mpkg from checking the python version available? (If yes, I may have another hacky way to do this.)
Help?
Thanks.
You have two main options to install gcc 4.2 on Snow Leopard:
Download pre-built binaries from osx-gcc-installer. This is the simplest way.
Download the Command Line Tools for Xcode package in the Developer Center and follow this guide to make it install on Snow Leopard.
In terminal type “gcc“, you will get message “command not found”.
C or GCC compiler is needed some times and MAC OS X does not have this installed by default
to install gcc compiler you will need to download and install command line tools for xcode (see Apples developer page)
I'm trying to install python-ldap on Mac OS X 10.6, but I get this error because it's using 10.4u.sdk instead of 10.6.sdk. How can I specify the SDK version to be used? So far, I tried specifying the MACOSX_DEPLOYMENT_TARGET env variable to 10.6 and SDKROOT to /Developer/SDKs/MacOSX10.6.sdk, but 10.4u.sdk was stil used. Any help is appreciated.
When installing Python packages with C extension modules on Mac OS X, Python will automatically use the SDK and deployment target with which the interpreter was built. Presumably you are using a 32-bit-only Python, perhaps from one of the python.org installers. These Pythons are built using the 10.4u SDK for compatibility with older systems. If you are using Xcode 3, the 10.4u SDK is not installed by default but you can run the Xcode 3 installer and select it. If you are using Xcode 4, you're probably out of luck as it does not include the 10.4u SDK (or so I understand). You can install a newer 64-bit/32-bit 10.6-only Python 2.7 from python.org or you could use the Apple-supplied Python 2.6 (/usr/bin/python2.6).
Is there an M2Crypto Windows installer for Python 2.7 64-bit? If not is there a reason why one cannot be built?
M2Crypto-0.21.1.win-amd64-py2.7 is available as part of the ActivePython Business Edition. M2Crypto is easy to build from the source distribution using Visual Studio 2008 but there are legal reasons why the binaries cannot be freely distributed.
You can try my Windows 64 build for Python 2.7:
http://brabenec.net/misc/packages/M2Crypto-0.21.1.win-amd64-py2.7.exe
http://brabenec.net/misc/packages/M2Crypto-0.21.1-py2.7-win-amd64.egg
Install via pip: pip install M2CryptoWin64 (for 64-bit Win) or pip install M2CryptoWin32 (for 32-bit). See this blog
It needs to install openssl-1.0.1b to get rid of issue
ImportError: DLL load failed: The specified module could not be found.