Develop Reference

I am trying to import another function from another module but I am getting this on an M1 Mac

I am importing another module in Jupyter.
Error message:
ImportError: dlopen(/Users/larrytsai/Repositories/payload-designer/.venv/lib/python3.10/site-packages/erfa/ufunc.cpython-310-darwin.so, 0x0002): tried: '/Users/larrytsai/Repositories/payload-designer/.venv/lib/python3.10/site-packages/erfa/ufunc.cpython-310-darwin.so' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64e'))

You need to install the arm64e version of the library you're trying to open.
MacOS can run x86_64 binaries using Rosetta, but it can't mix an x86_64 version with the arm64e interpreter.
Edit: Trying it out on my M1 Mac, it properly built the pyerfa package, you probably just need to uninstall and reinstall it to coerce the rebuild.
It actually built both architectures:
$ file ufunc.cpython-310-darwin.so
ufunc.cpython-310-darwin.so: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit bundle x86_64Mach-O 64-bit bundle x86_64] [arm64:Mach-O 64-bit bundle arm64Mach-O 64-bit bundle arm64]
ufunc.cpython-310-darwin.so (for architecture x86_64): Mach-O 64-bit bundle x86_64
ufunc.cpython-310-darwin.so (for architecture arm64): Mach-O 64-bit bundle arm64

CMake finds suitable Python version, but cannot use interpreter

I am trying to upgrade QGIS from 3.10 to 3.20 and this requires upgrading CMake to >=3.15 and Python >= 3.7. I am using an EOL Linux distribution (Fedora 28, upgrading the OS is the obvious easy fix but this has to be done on 28, no questions asked). I've installed both CMake (3.19.4) and Python (3.7.9) to my local directories, set them to path, and have added the following CMake options:
cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=/usr/local -DWITH_SERVER=ON \
-DPYTHON_EXECUTABLE=/usr/local/bin/python3.7 -D......
yet I receive the following error:
CMake Error at /usr/local/share/cmake-3.19/Modules/FindPackageHandleStandardArgs.cmake:218 (message):
Could NOT find Python (missing: Python_EXECUTABLE Interpreter) (found
suitable version "3.7.9", minimum required is "3.7")
Reason given by package:
Interpreter: Cannot use the interpreter "/usr/local/bin/python3.7"
Call Stack (most recent call first):
/usr/local/share/cmake-3.19/Modules/FindPackageHandleStandardArgs.cmake:582 (_FPHSA_FAILURE_MESSAGE)
/usr/local/share/cmake-3.19/Modules/FindPython/Support.cmake:3148 (find_package_handle_standard_args)
/usr/local/share/cmake-3.19/Modules/FindPython.cmake:428 (include)
CMakeLists.txt:946 (find_package)
Any suggestions on how to proceed? I've added the flags "-DCMAKE_PYTHON_INCLUDE_DIR" and "-DCMAKE_PYTHON_LIBRARY", made sure I configured the local Python to have shared libraries enabled and this either changes nothing or reverts to finding the older Python on my path (3.6.8).

python3 configure script error - could not find pthreads

I am trying to compile python 3.7.7 on mac os Big Sur.
Downloaded the source code from python.org
running the configure script exits on error
configure: error: could not find pthreads on your system
cmake version 3.19.0
gcc version
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 11.0.0 (clang-1100.0.33.17)
Target: x86_64-apple-darwin20.1.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

Python is 32-bit, chosen compiler is 64-bit [duplicate]

I'm trying to compile pybind11 on a Windows machine that has VisualStudio 2015 installed. I also have python 3.5.3 64bit installed, and cmake 2.8.12. I get the error:
CMake Error at tools/FindPythonLibsNew.cmake:122 (message):
Python config failure: Python is 64-bit, chosen compiler is 32-bit
Call Stack (most recent call first):
tools/pybind11Tools.cmake:16 (find_package)
CMakeLists.txt:28 (include)
I did not "choose" the compiler to be 32-bit, and looking at the CMakeLists.txt, I did not find any place to specify which compiler to run.
So how to I tell pybind11/cmake to compile for 64 bit?

You should specify the 64-bit VS compiler like so:
cmake "/path/to/src/" -G"Visual Studio 14 2015 Win64"
Otherwise it selects the 32-bit by default.

If you are using the Ninja generator and you have this error make sure you run the VS Dev command prompt in 64-bit mode:
VsDevCmd.bat arch=amd64 && cmake <options> ...

You can either do :
cmake .. -G"Visual Studio 14 2015 Win64"
cmake --build . --config Release --target check
or based on this quote from the Compiling the test cases for windows section here:
If all tests fail, make sure that the Python binary and the testcases
are compiled for the same processor type and bitness (i.e. either i386
or x86_64). You can specify x86_64 as the target architecture for the
generated Visual Studio project using cmake -A x64 ..
You can do :
cmake -A x64 ..
cmake --build . --config Release --target check

Can't load mysqlclient.18.dylib into python on Mac OS Lion

I want to get MySQL working with the system Python 2.7 in Mac OS X Lion.
I know there are a lot of questions very similar to this out there, and in fact my symptom is identical to mysql-python installation problems (on mac os x lion). However, that answer doesn't seem to apply to my case.
My Mac is a current MacBook Pro running the 64-bit kernel:
% uname -a
Darwin Leos-MacBook-Pro.local 11.2.0 Darwin Kernel Version 11.2.0: Tue Aug 9 20:54:00 PDT 2011; root:xnu-1699.24.8~1/RELEASE_X86_64 x86_64
The stock python on Lion is a fat binary:
% file /usr/bin/python
/usr/bin/python: Mach-O universal binary with 2 architectures
/usr/bin/python (for architecture x86_64): Mach-O 64-bit executable x86_64
/usr/bin/python (for architecture i386): Mach-O executable i386
I had used Migration Assistant so my system had an old installation of MySQL on it. I used the instructions at How to remove installation of MySQL on Mac OS X to remove the old MySQL installation.
MySQL 64-bit 5.5.19 was installed from the .dmg on the MySQL site. As usual, this placed the client library in /usr/local/mysql/lib. The client library appears to be exactly what we want:
% file /usr/local/mysql/lib/libmysqlclient.18.dylib
/usr/local/mysql/lib/libmysqlclient.18.dylib: Mach-O 64-bit dynamically linked shared library x86_64
However, that shared library can't be loaded into python (I'm using the arch command to make absolutely sure I'm running the 64-bit image although the result is the same with or without that):
% arch -x86_64 python
Python 2.7.1 (r271:86832, Jul 31 2011, 19:30:53)
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from ctypes import cdll
>>> cdll.LoadLibrary("/usr/local/mysql/lib/libmysqlclient.18.dylib")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ctypes/__init__.py", line 431, in LoadLibrary
return self._dlltype(name)
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ctypes/__init__.py", line 353, in __init__
self._handle = _dlopen(self._name, mode)
OSError: dlopen(/usr/local/mysql/lib/libmysqlclient.18.dylib, 6): no suitable image found. Did find:
/usr/local/mysql/lib//libmysqlclient.18.dylib: mach-o, but wrong architecture
/usr/local/mysql/lib/libmysqlclient.18.dylib: mach-o, but wrong architecture
I can reproduce this problem many other ways, notably by using the standard import MySQLdb; I'm showing the ctypes way of reproducing the bug specifically because I was trying to figure out whether the problem was in mysql-python or in the MySQL client library. From the above, it seems to be the client library. However, I'm baffled as to why the loader thinks the client library is the wrong architecture.
In trying to see whether it's some dependent library that's the problem, I checked the dependencies in libmysqlclient.18.dylib:
% otool -L /usr/local/mysql/lib/libmysqlclient.18.dylib
/usr/local/mysql/lib/libmysqlclient.18.dylib:
libmysqlclient.18.dylib (compatibility version 18.0.0, current version 18.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.0.1)
And of course /usr/lib/libSystemB.dylib is a fat binary as expected:
% file /usr/lib/libSystem.B.dylib
/usr/lib/libSystem.B.dylib: Mach-O universal binary with 2 architectures
/usr/lib/libSystem.B.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64
/usr/lib/libSystem.B.dylib (for architecture i386): Mach-O dynamically linked shared library i386
So... Python is 64-bit, the mysqlclient library is 64-bit, and the dependent libraries are all 64-bit... Any guesses as to why the loader is refusing the import the library would be very welcome.
Just for the belt-and-suspenders checking that everything's 64-bit-y:
% python -c 'import platform; print platform.platform()'
Darwin-11.2.0-x86_64-i386-64bit
% ls -l /usr/local/mysql
lrwxr-xr-x 1 root wheel 27 Dec 10 16:52 /usr/local/mysql# -> mysql-5.5.19-osx10.6-x86_64
At this point, since I need to actually get some work done, I'm going to try switching to pymysql. This is mostly for use with Django, for which there's a convenient way to swap pymysql in documented at the bottom of this thread.
P.S. I understand macports and can't use it on this system.

Chances are you have set the default execution mode of the Apple-supplied Python to 32-bits, either by using defaults or by setting the VERSIONER_PYTHON_PREFER_32_BIT environment variable; see man python for details. In OS X 10.6 and 10.7 /usr/bin/python is an Apple-supplied wrapper program that determines which Python to run and in which mode. Using arch to execute /usr/bin/python will not influence the interpreter. For example:
$ unset VERSIONER_PYTHON_PREFER_32_BIT
$ arch -x86_64 /usr/bin/python -c "import sys;print(sys.maxsize)"
9223372036854775807
$ export VERSIONER_PYTHON_PREFER_32_BIT=yes
$ arch -x86_64 /usr/bin/python -c "import sys;print(sys.maxsize)"
2147483647
#
# But avoiding the wrapper program ....
#
$ arch -x86_64 /usr/bin/python2.7 -c "import sys;print(sys.maxsize)"
9223372036854775807
$ arch -i386 /usr/bin/python2.7 -c "import sys;print(sys.maxsize)"
2147483647