Develop Reference

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

How to build MultiNEAT from sources?

I'm building MultiNEAT from source, on macOS Mojave, with Python3, and I'm hitting a snag when trying "python setup.py build_ext". I get a bunch of errors. Any help is greatly appreciated.
Here is a step by step of what I'm doing from scratch, if you want to follow along in your own terminal. I'm doing all of this so others can do it themselves too, as it has taken me a while to even get here. I've gotten bits and pieces of information here and there, but there is no straight up instructions on how to build this library.
# Change things accordingly for you.
# Define work dir. Should be empty at this point.
WDIR=/Users/luis/Documents/neat
cd $WDIR
# Setup Python virtual environment and requirements.
python3 -m venv venv
. venv/bin/activate
pip install --upgrade pip
pip install psutil numpy opencv-python
# Get Boost.
# Get the url from here: https://www.boost.org/users/download/
curl -L https://dl.bintray.com/boostorg/release/1.70.0/source/boost_1_70_0.tar.gz | tar -xz
cd boost_1_70_0/
# Get system Python include files with: python3-config --includes
# Put that path into this exported var.
export CPLUS_INCLUDE_PATH=/Library/Frameworks/Python.framework/Versions/3.7/include/python3.7m
# Build Boost! This will take a bit.
./bootstrap.sh --prefix=$WDIR/boost
./b2 install
# Get MultiNEAT.
cd $WDIR
git clone https://github.com/peter-ch/MultiNEAT.git
cd MultiNEAT/
# Setup build. (Is this incomplete?)
export MN_BUILD=boost
export PREFIX=$WDIR/boost
# Build MultiNEAT!
python setup.py build_ext
# Supposedly, I'd do "python setup.py install" after, but errors are happening now :(
This is only the top part of when errors start happening, but most are similar:
In file included from src/Innovation.cpp:34:
In file included from src/Innovation.h:37:
src/Genome.h:689:19: error: expected ':'
public void set_children()
^
:
src/Genome.h:691:49: error: indirection requires pointer operand ('std::__1::vector<double,
std::__1::allocator<double> >::size_type' (aka 'unsigned long') invalid)
for(unsigned int ix = 0; ix < 2**coord.size(); ix++){
^~~~~~~~~~~~~

Here is what works:
First install the dependencies you want to use:
Boost 1.49 and above with Boost.Python and Boost.Serialization (optional)
ProgressBar (Python package) (optional)
NumPy (Python package) (optional)
Matplotlib (Python package) (optional)
OpenCV 2.3 and above (with Python bindings) (optional)
Cython (if you want Python bindings)
Then clone this git(this one seems to be older but does not throw those errors you encountered)
And finally enter the source directory and run "sudo python setup.py install"
This worked even with Python 3.7.

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

Cmake is not able to find Python-libraries

Getting this error:
sudo: unable to resolve host coderw#ll
-- Could NOT find PythonLibs (missing: PYTHON_LIBRARIES PYTHON_INCLUDE_DIRS)
CMake Error at /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:108
(message):
Could NOT find PythonInterp (missing: PYTHON_EXECUTABLE)
Call Stack (most recent call first):
/usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:315
(_FPHSA_FAILURE_MESSAGE)
/usr/share/cmake-2.8/Modules/FindPythonInterp.cmake:139
(FIND_PACKAGE_HANDLE_STANDARD_ARGS)
Code/cmake/Modules/FindNumPy.cmake:10 (find_package)
CMakeLists.txt:114 (find_package)
-- Configuring incomplete, errors occurred!
See also "/home/coderwall/Desktop/rdkit/build/CMakeFiles/CMakeOutput.log".
See also "/home/coderwall/Desktop/rdkit/build/CMakeFiles/CMakeError.log".
I have already installed:
sudo apt-get install python-dev
Environment variable are already set as follow:
PYTHON_INCLUDE_DIRS=/usr/include/python2.7
PYTHON_LIBRARIES=/usr/lib/python2.7/config/libpython2.7.so
Location of python.h : /usr/lib/include/python2.7/python.h
Location of python libs: /usr/lib/python2.7/
How to solve this?

You can fix the errors by appending to the cmake command the -DPYTHON_LIBRARY and -DPYTHON_INCLUDE_DIR flags filled with the respective folders.
Thus, the trick is to fill those parameters with the returned information from the python interpreter, which is the most reliable. This may work independently of your python location/version (also for Anaconda users):
$ cmake .. \
-DPYTHON_INCLUDE_DIR=$(python -c "import sysconfig; print(sysconfig.get_path('include'))") \
-DPYTHON_LIBRARY=$(python -c "import sysconfig; print(sysconfig.get_config_var('LIBDIR'))")
If the version of python that you want to link against cmake is Python3.X and the default python symlink points to Python2.X, python3 -c ... can be used instead of python -c ....
In case that the error persists, you may need to update the cmake to a higher version as stated by #pdpcosta and repeat the process again.

For me this is helpful:
# if using python2
apt-get install python-dev
# if using python3
apt-get install python3-dev

I hit the same issue,and discovered the error message gives misleading variable names. Try setting the following (singular instead of plural):
PYTHON_INCLUDE_DIR=/usr/include/python2.7
PYTHON_LIBRARY=/usr/lib/python2.7/config/libpython2.7.so
The (plural) variables you see error messages about are values that the PythonLibs sets up when it is initialised correctly.

Even after adding -DPYTHON_INCLUDE_DIR and -DPYTHON_LIBRARY as suggested above, I was still facing the error Could NOT find PythonInterp. What solved it was adding -DPYTHON_EXECUTABLE:FILEPATH= to cmake as suggested in https://github.com/pybind/pybind11/issues/99#issuecomment-182071479:
cmake .. \
-DPYTHON_INCLUDE_DIR=$(python -c "from distutils.sysconfig import get_python_inc; print(get_python_inc())") \
-DPYTHON_LIBRARY=$(python -c "import distutils.sysconfig as sysconfig; print(sysconfig.get_config_var('LIBDIR'))") \
-DPYTHON_EXECUTABLE:FILEPATH=`which python`

I was facing this problem while trying to compile OpenCV 3 on a Xubuntu 14.04 Thrusty Tahr system.
With all the dev packages of Python installed, the configuration process was always returning the message:
Could NOT found PythonInterp: /usr/bin/python2.7 (found suitable version "2.7.6", minimum required is "2.7")
Could NOT find PythonLibs (missing: PYTHON_INCLUDE_DIRS) (found suitable exact version "2.7.6")
Found PythonInterp: /usr/bin/python3.4 (found suitable version "3.4", minimum required is "3.4")
Could NOT find PythonLibs (missing: PYTHON_LIBRARIES) (Required is exact version "3.4.0")
The CMake version available on Thrusty Tahr repositories is 2.8.
Some posts inspired me to upgrade CMake.
I've added a PPA CMake repository which installs CMake version 3.2.
After the upgrade everything ran smoothly and the compilation was successful.

Some last version of Ubuntu installs Python 3.4 by default and the CMake version from Ubuntu (2.8) only searches up to Python 3.3.
Try to add set(Python_ADDITIONAL_VERSIONS 3.4) before the find_package statement.
Remember to clean CMakeCache.txt too.

This problem can also happen in Windows. Cmake looks into the registry and sometimes python values are not set. For those with similar problem:
http://ericsilva.org/2012/10/11/restoring-your-python-registry-in-windows/
Just create a .reg file to set the necessary keys and edit accordingly to match your setup.
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Python]
[HKEY_CURRENT_USER\Software\Python\Pythoncore]
[HKEY_CURRENT_USER\Software\Python\Pythoncore\2.6]
[HKEY_CURRENT_USER\Software\Python\Pythoncore\2.6\InstallPath]
#="C:\\python26"
[HKEY_CURRENT_USER\Software\Python\Pythoncore\2.6\PythonPath]
#="C:\\python26;C:\\python26\\Lib\\;C:\\python26\\DLLs\\"
[HKEY_CURRENT_USER\Software\Python\Pythoncore\2.7]
[HKEY_CURRENT_USER\Software\Python\Pythoncore\2.7\InstallPath]
#="C:\\python27"
[HKEY_CURRENT_USER\Software\Python\Pythoncore\2.7\PythonPath]
#="C:\\python27;C:\\python27\\Lib\\;C:\\python27\\DLLs\\"

Note that if you are using cMake version 3.12 or later, variable PythonInterp and PythonLibs has been changed into Python.
So we use:
find_package(Python ${PY_VERSION} REQUIRED)
instead of:
find_package(PythonInterp ${PY_VERSION} REQUIRED)
find_package(PythonLibs ${PY_VERSION} REQUIRED)
see https://cmake.org/cmake/help/v3.12/module/FindPython.html for details.

I had upgraded to python3.8 on my system and had an incomplete install. Managed to fix it by installing the rest of the 3.8 packages:
sudo apt-get install python3.8 python3.8-dev python3.8-distutils python3.8-venv

Paste this into your CMakeLists.txt:
# find python
execute_process(COMMAND python-config --prefix OUTPUT_VARIABLE PYTHON_SEARCH_PATH)
string(REGEX REPLACE "\n$" "" PYTHON_SEARCH_PATH "${PYTHON_SEARCH_PATH}")
file(GLOB_RECURSE PYTHON_DY_LIBS ${PYTHON_SEARCH_PATH}/lib/libpython*.dylib ${PYTHON_SEARCH_PATH}/lib/libpython*.so)
if (PYTHON_DY_LIBS)
list(GET PYTHON_DY_LIBS 0 PYTHON_LIBRARY)
message("-- Find shared libpython: ${PYTHON_LIBRARY}")
else()
message(WARNING "Cannot find shared libpython, try find_package")
endif()
find_package(PythonInterp)
find_package(PythonLibs ${PYTHON_VERSION_STRING} EXACT)

In case that might help, I found a workaround for a similar problem, looking at the cmake doc :
https://cmake.org/cmake/help/v3.0/module/FindPythonLibs.html
You must set two env vars for cmake to find coherent versions.
Unfortunately this is not a generic solution...
cmake -DPYTHON_LIBRARY=${HOME}/.pyenv/versions/3.8.0/lib/libpython3.8.a -DPYTHON_INCLUDE_DIR=${HOME}/.pyenv/versions/3.8.0/include/python3.8/ cern_root/

In Python 3.2 and onward distutils.sysconfig is deprecated in favor of sysconfig.
To get all the variable names in data structure and inspect the situation we can use get_paths function
import sysconfig
sysconfig.get_paths()
which will return us a dict with all the relevant variable names as keys, and corresponding paths as values.
When we know the key we can get the value dynamically,
>>> sysconfig.get_path("include")
'C:\\Program Files\\Python310\\Include'
However, the most convenient feature of sysutils for this situation is that it can list all the variables at once from the command-prompt by invoking python -m sysconfig:
$ python -m sysconfig
Platform: "macosx-10.4-i386"
Python version: "3.2"
Current installation scheme: "posix_prefix"
Paths:
data = "/usr/local"
include = "/Users/tarek/Dev/svn.python.org/py3k/Include"
platinclude = "."
platlib = "/usr/local/lib/python3.2/site-packages"
platstdlib = "/usr/local/lib/python3.2"
purelib = "/usr/local/lib/python3.2/site-packages"
scripts = "/usr/local/bin"
stdlib = "/usr/local/lib/python3.2"
Variables:
AC_APPLE_UNIVERSAL_BUILD = "0"
AIX_GENUINE_CPLUSPLUS = "0"
AR = "ar"
ARFLAGS = "rc"
...

Maybe below command line works for you if all of above methods didn't work.
sudo apt-get install cython cython3

On Ubuntu 20 at least, since Python 2.7 is deprecated, you can:
sudo apt install python2.7-dev
And then PYTHON_INCLUDE_DIR can be set to /usr/include/python2.7

_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.