Develop Reference

Python delocate-wheel breaks wheel on MacOS

I'm generating wheel files to support a python distribution on MacOS using delocate. The wheels rely on libraries installed when gcc is installed using Homebrew.
brew install -v gcc#10
/usr/local/Cellar/gcc/10.2.0_3/lib/gcc/10/libstdc++.6.dylib
/usr/local/lib/gcc/10/libgcc_s.1.dylib
When running delocate-wheel with verbose option, the above are the two libraries included in the wheel.
If I use pip to install the original wheel, I can run the program without issue.
After running delicate-wheel and installing the new de-located wheel and trying to run, I produce this error:
python(66449,0x105ea3dc0) malloc: *** error for object 0x1071c3b60: pointer being freed was not allocated
python(66449,0x105ea3dc0) malloc: *** set a breakpoint in malloc_error_break to debug
I have tried using the require-archs=intel, but this errors out, and it appears that I only have single architecture files: Non-fat file: /usr/bin/python is architecture: x86_64
thank you,

Compiling GTK+3 by Using Meson

GTK+3 v3.24 is downloaded from Gitlab and extracted from zip file.
After running Meson, it gives the following error when meson setup --prefix C:\Users\user\Desktop\gtk\gtk-gtk-3-24 builddir command is run:
meson.build:359:0: ERROR: Git program not found.
No Git programs are installed on my machine (Windows 10 x64). But source code is downloaded. Meson and Ninja are installed by using pip command.
What is the problem?

The problem that in addition to GTK sources you need to provide all required dependencies: some dependency is not found -> meson tries to use "fallback", i.e. download some subproject from git, probably this is glib dependency:
glib_dep = dependency('glib-2.0', version: glib_req,
fallback : ['glib', 'libglib_dep'])
Here you can find the list of some of required packages:
You will also need various dependencies, based on the platform you are
building for:
GLib
GdkPixbuf
GObject-Introspection
...
But instead of painful process of setting up all these, why not just trying to use tool that is recommended to setup GTK on Windows? Check gvsbuild project or MSYS2, both described here.

Cannot install nlopt python module

I am trying to install nlopt onto macOS 10.15.5. I downloaded the nlopt-2.6.2.tar.gz file from the NLopt docs and ran the following from the nlopt-2.6.2 directory:
mkdir build
cd build
cmake -DNLOPT_OCTAVE=Off -DNLOPT_MATLAB=Off -DNLOPT_GUILE=Off ..
make
sudo make install
I got the following output: cmake.txt.
The header file (nlopt.h) installs correctly to /usr/local/include and the dynamic library (libnlopt.dylib) installs correctly to /usr/local/lib/, but neither the dist-info file nor the nlopt module itself installs.
I have also tried installing via pip, brew, and conda, none of which have worked. I have also tried cloning from this Github, which didn't work either.
I appreciate any help with this, because I am completely lost. I am relatively new to this kind of stuff, and I couldn't find any good answers online.

The official docs are somewhat laconic about the exact steps required for building nlopt with Python bindings. First of all, you'll need SWIG installed:
$ brew install swig
Then, you'll need numpy to be available for the target Python interpreter. It is already preinstalled for the system Python, otherwise install it via Homebrew or pip, depending on your Python installation.
Now run cmake:
$ cmake -DNLOPT_GUILE=OFF -DNLOPT_MATLAB=OFF -DNLOPT_OCTAVE=OFF -DNLOPT_TESTS=OFF
This will build bindings against the default Python 2.7 installation preinstalled on MacOS. If you need to build against custom Python installation (e.g. when you've installed Python 3 via Homebrew or PKG installer from https://www.python.org/downloads), pass it via the PYTHON_EXECUTABLE arg:
$ cmake -DNLOPT_GUILE=OFF -DNLOPT_MATLAB=OFF -DNLOPT_OCTAVE=OFF -DNLOPT_TESTS=OFF -DPYTHON_EXECUTABLE=/usr/local/bin/python3
Inspect the log now - Python, SWIG and numpy headers should be successfully located. Example output snippet (you may have different paths/versions printed):
-- Found PythonInterp: /usr/local/bin/python3.8 (found version "3.8.3")
-- Found PythonLibs: /Library/Frameworks/Python.framework/Versions/3.8/lib/libpython3.8.dylib (found suitable exact version "3.8.3")
-- Found NumPy: /Users/hoefling/Library/Python/3.8/lib/python/site-packages/numpy/core/include (found version "1.19")
-- Found SWIG: /usr/local/bin/swig (found version "4.0.2")
If any of those conditions is not satisfied (e.g. you see Could NOT find NumPy, Could NOT find PythonLibs or Could NOT find SWIG), then stop and make sure the configuration succeeds before proceeding next.
Now compile:
$ make
...
Scanning dependencies of target nlopt_python_swig_compilation
[ 96%] Swig compile nlopt.i for python
[ 96%] Built target nlopt_python_swig_compilation
Scanning dependencies of target nlopt_python
[ 98%] Building CXX object src/swig/CMakeFiles/nlopt_python.dir/CMakeFiles/nlopt_python.dir/nloptPYTHON_wrap.cxx.o
[100%] Linking CXX shared module _nlopt.so
[100%] Built target nlopt_python
Install:
$ make install
...
-- Installing: /usr/local/lib/python3.8/site-packages/nlopt.py
-- Installing: /usr/local/lib/python3.8/site-packages/_nlopt.so
Test the Python bindings are importable:
$ python -c "import nlopt; print(nlopt.__version__)"
2.6.2

gmpy2 installs but can't find libmpc.so.3

I want to use gmpy2 with python 2.7 but when I try to import it I get:
>>> import gmpy2
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: libmpc.so.3: cannot open shared object file: No such file or directory
I installed gmpy2 using pip: pip install -user gmpy2 and the install looks ok apart from saying
Could not find .egg-info directory in install record for gmpy2
but after that it says that the install was a success.
I have installed MPC (1.0.3), GMP (6.1.1) and MPFR (3.1.4) and they all work, by which I mean I can call gcc foo.c -lmpc and gcc bar.c -lmpfr and the code compiles and works as expected. I've also got gmpy working using pip install. I think the problem will be to do with them not being installed in the default directories as I don't have sudo rights.
The directory where libmpc.so.3 is located is in the gcc call that pip spits out, I've also set CPATH and CPPFLAGS to look in my_prefix/include and LDFLAGS to look my_prefix/lib.
I don't really want to use the functionality from MPC so if there's a simple option to not install that part of gmpy2 I'd be happy with that.
I'm really confused, I've had it that pip fails to build a library and I've gone away and installed dependencies but normally once a library is passed pip it works.

I maintain gmpy2 and there are a couple of command line options that can be passed to setup.py that may help. I can't test the pip syntax right now but here are some options:
--shared=/path/to/gmp,mpfr,mpc will configure gmpy2 to load the libraries from the specified directory.
--static or --static=/path/to/gmp,mpfr,mpc will create a statically linked version of gmpy2 if the proper libraries can be found.
You can also try a build using setup.py directly. It may produce better error messages. Again, untested command:
python setup.py build_ext --static=/path/to/gmp,mpfr,mpc should compile a standalone, staticly linked gmpy2.so which will need to moved to the appropriate location.
Update
I've been able to test the options to pip.
If you are trying to use versions of GMP, MPFR, and MPC that are not those provided by the Linux distribution, you will need to specify the location of the new files to the underlying setup.py that is called by pip. For example, I have updated versions installed locally in /home/case/local. The following command will configure gmpy2 to use those versions:
pip install --install-option="--shared=/home/case/local" --user gmpy2
To compile a statically linked version (for example, to simplify distribution to other systems in cluster), you should use the following:
pip install --install-option="--static=/home/case/local" --user gmpy2
setup.py will use the specified base directory to configure the correct INCLUDE path (/home/case/local/include) and runtime library path (/home/case/local/lib).

Try to do the following as it might me fixed in an older version:
pip install --upgrade setuptools pip
pip uninstall gmpy2
pip install gmpy2

_imaging C module error in python PIL

I have read the other posts about the notorious _imaging C module error when installing PIL on Mac OS X and none of the solutions provided anywhere, including the PIL FAQ, have proven helpful.
I have the newest versions of libjpeg and zlib freshly installed from source. I have edited the Makefiles in each of these to include the option -arch i386 in the LD_FLAGS variable for 32-bit builds. PIL installs with no problems of any kind and the install summary printed to the terminal says that JPEG, TIFF, and PNG support are all OK. After that I try the self test:
new-host:Imaging-1.1.7 ely$ python selftest.py
*** The _imaging C module is not installed
This is commonly seen for a variety of reasons. Probing deeper, here I try to import _imaging directly in python.
new-host:Imaging-1.1.7 ely$ python
ActivePython 2.7.1.4 (ActiveState Software Inc.) based on
Python 2.7.1 (r271:86832, Feb 7 2011, 11:33:10)
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import PIL
>>> import _imaging
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/PIL/_imaging.so, 2): Symbol not found: _jpeg_resync_to_restart
Referenced from: /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/PIL/_imaging.so
Expected in: dynamic lookup
Here again, the 'Symbol not found: _jpeg_resync_to_restart' is notorious and common, and many people have suggested this has to do with incorrect path to libjpeg. I've checked again and again and I only have libjpeg (as well as zlib, etc.) installed in my home directory, all in separate folders, from source, and all of this is marked correctly in the file setup.py.
So, PIL should be getting its jpeg support (and zlib, etc.) from the right places. All the dependencies are installed. I can see _imaging.so in my sys.path, yet I still get this _jpeg_resync_to_restart error.
Are there any ideas that don't link to alternate posts? I have spent ~7 hours reading and trying possible solutions from posts in every forum I can find.

Since you have been trying this a few times, I recommend running a few commands to clean out the old items first and start from the beginning.
I used jpeg v8c and Imaging 1.1.6 on Mac OS X, 10.6 and 10.7
get v8c of jpeg
cd into jpeg directory.
sudo make clean
CC="gcc -arch i386" ./configure --enable-shared --enable-static
make
sudo make install
get imaging i am using 1.1.6
untar
cd into imaging
sudo rm -rf build
vi setup.py
JPEG_ROOT = libinclude(“/usr/local/lib”)
sudo python setup.py install
And it’s that simple
Run your python interpreter,
import PIL
import _imaging
import Image
if all is well, then your all set.
Here is the full article on my blog Python 2.7, OSX Lion, PIL and Imaging

I have faced the same problem this evening on my mac running Mac OS X v10.7.5, Python v2.7.1 with PIL Imaging 1.1.7 and jpeg 8d.
Summarizing - the key to success in my case was:
export ARCHFLAGS="-arch x86_64"
Nothing from the other answers have solved the issue, constantly I've been getting:
The _imaging C module is not installed caused by:
Symbol not found: _jpeg_resync_to_restart.
Digging here and there finally I've found the solution, at least works for me:
ensure you don't have any obvious libjpeg libs on the system: find / -iname "libjpe*" will tell you that. I have temporarily changed places where they exist so no one could find them (especially /sw was interacting with PIL in my case):
mv opt opt-OFF
mv sw sw-OFF
These locations have been created by mac ports and fink - be warned that it is quite possible that FREETYPE2 might not be found by PIL after this move - if you need it, then just rename libjpeg parts in those locations.
in PIL Imaging src directory edit setup.py as described above to set JPEG_ROOT to /usr/local, try to run:
rm -rf build ; python setup.py build 2> /tmp/err > /tmp/log
Check in /tmp/log - you should not see JPEG support available. You can now go to the next step.
go to jpeg-8d src directory and run:
export ARCHFLAGS="-arch x86_64"
sudo make clean; CC="gcc -arch x86_64" ./configure --enable-shared --enable-static
sudo make install
go back to PIL Imaging, run these commands:
export ARCHFLAGS="-arch x86_64"
sudo rm -rf build ; python setup.py build 2> /tmp/err > /tmp/log
Check in /tmp/log - you should now see "JPEG support available", check /tmp/err - search for "jpeg" - if you see something like this:
ld: warning: ignoring file /usr/local/lib/libjpeg.dylib, file was built for unsupported file format which is not the architecture being linked (i386) - then the arch flags (both set by ARCHFLAGS and -arch) failed to trigger - investigate that case, it is crucial. If you don't see this, then you're lucky and you can invoke the installation:
export ARCHFLAGS="-arch x86_64"
sudo rm -rf build ; sudo python setup.py install
Check if your PIL works:
python selftest.py
or
echo "import _imaging" | python && echo "Works"
I hope this helps.

The problem is that the _imaging module is linked to libjpeg dynamically, not statically. The libjpeg code is not included in the _imaging module directly. This means that your platform's dynamic linker has to be able to find libjpeg in order to load and link it. My MacOS knowledge here is fuzzy, but as I recall its dynamic linker is called dyld, and its manpage may provide more information on the options you have.
Normally, the platform's dynamic linker won't be looking in your homedirectory for libraries -- but you can tell it to, for example by setting the DYLD_LIBRARY_PATH environment variable, or editing the system-wide configuration (if there is one.) Setting that environment variable usually has to be done before you start Python, though, so it may not be suitable. You may want to try to embed the runtime search path into the _imaging extension module, which is usually done by passing -rpath to the linker -- but I don't know if MacOS's linker offers that capability. Finally, you can just build libjpeg as a static library, instead of a shared one, and have the _imaging module link against that. That would avoid the whole shared library situation for libjpeg. For libjpeg, this is probably done by running its configure script with --enable-static --disable-shared.

I tried many most all of these suggestions (as well as two other suggestions on referenced blogs) on an old 10.6 Mac install. None of them worked as-is, however, reading behind the lines I was able to fix my problem. I added to the PIL setup.py in find_include_file() right before the return 1 line "print os.path.join(directory, include)". This allowed me to track down which libjpeg PIL is building against. Then I would build PIL, find the libjpeg it referenced (various copies in /sw, /opt/, /usr/local/lib, ...), and delete that libjpeg (both header and lib files).
Finally with a clean system I built and installed libjpeg source tarball that I'd downloaded myself, followed by building and installing PIL from source. This worked. As a fallback you could always disable libjpeg by removing the above files as described or else always returning zero from the described above function in setup.py.

Works well for me on Mountain Lion 10.8.2:
Step One. Removing all jpeg packages. For MacPorts:
sudo port -f uninstall jpeg or sudo port -f uninstall jpeg #version_here
We need to remove all jpeg versions!
Step Two. Remove PIL: pip uninstall PIL
Step Three. Install jpeg package again. For MacPorts: sudo port install jpeg
Step Four. Install PIL again: pip install PIL
>>> import PIL
>>> import _imaging
No errors!
How to remove ALL jpeg packages?
$ port installed | grep -i jpeg
jpeg #8c_0
jpeg #9a_0 (active)
$ sudo port -f uninstall jpeg #8c_0
$ sudo port -f uninstall jpeg #9a_0
Don't care about dependies. Beacause we need to install jpeg package again:
$ sudo port install jpeg

I ran into all the errors you guys have mentioned. I broke down and just used virtualenv and installed Pillow instead. it worked:
sudo pip install virtualenv
virtualenv python_script && cd !$
. /activate/bin
pip install Pillow

I had the same problem, with Python 2.7 and OSX Lion, and basically followed #ApPeL process and re-installed libjpeg and PIL. libjpeg seemed to be installed correctly, and PIL seemed to find it correctly, but running python -v and then import _imaging gave always this error:
ImportError:
dlopen(/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/PIL/_imaging.so,
2): Symbol not found: _jpeg_resync_to_restart
After installing and re-installing libjpeg (version 8d) and PIL (version 1.1.7) twenty times with slightly different options, what did the trick was making sure I removed all libjpeg files under /usr/local/include (headers), as well as the files under /user/local/lib.
I didn't need to install PIL from source, I used pip install pil

This worked for me-
http://www.thetoryparty.com/2010/08/31/pil-on-snow-leopard-_jpeg_resync_to_restart-error/

I have been attempting to install PIL (OS X 10.7.5, Python 2.7.3) for about 5 hours. I too have been bogged down with the 'Symbol not found: _jpeg_resync_to_restart" error and have tried many of the proposed solutions to no avail, including reinstalling all of its dependencies. Finally, I discovered a double-clickable installation of Pillow.
Thank you Rudix! Now "import PIL" and "import _imaging" work!
p.s. I had installed libjpeg via i didn't specifically delete this install, so I'm not sure if this was part of the final solution or not.