E
Erik Johnson
This has apparently been a problematic thing for a while now, as the
following article indicates. I first ran into the error message about
not being able to remap C:\cygwin\bin\tk84.dll to be the same address
as it's parent.
Using that information, Google helped me find this article:
http://blog.datahammer.info/2008/11/install-pil-under-cygwin-python-25.html
After following it's advice and running:
$ ./rebase -b 0x1000000000 tk84.dll
I was able to get the PIL build to proceed, but when it was done, it
said that there was no support built for Tk, and I then noticed that
basic Tkinter functionality was broken from the Python interpreter.
I went back to Cygwin setup, and had it reinstall the tcl/tk package,
and then Tkinter (import from the interactive interp.) got fixed.
Googling some more, I found this article (which implied datahammer
isn't quite right): http://www.pythonchallenge.com/forums/viewtopic.php?t=135
I ran /usr/bin/rebaseall (from ash)(and if you end up doing this
yourself, be aware that it takes a while - I was afraid that process
had hung and I was going to have to rebuild the whole Cygwin shooting
match from scratch, but it eventually completed (silently)).
After this, I checked that Tkinter still worked from Python (it did),
and then tore out the whole PIL directory (Imaging-1.1.6) I had tried
to install from before, re-extracted the tar file to get a clean
install directory, and then again attempted to build PIL. Now,
instead of getting the failure message about not being able to remap
the dll, the build just hangs:
$ python setup.py build_ext -i
running build_ext
building '_imaging' extension
creating build
creating build/temp.cygwin-1.5.25-i686-2.5
creating build/temp.cygwin-1.5.25-i686-2.5/libImaging
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-
prototypes -DHAVE_LIBJPEG -DHAVE_LIBZ -I/usr/include/freetype2 -
IlibImaging -I/usr/include -I/home/ej/python/PIL/jpeg-6b -I/usr/
include/python2.5 -c _imaging.c -o build/temp.cygwin-1.5.25-i686-2.5/
_imaging.o
<eventually hit CTRL-C to leave>
Now, I'm rather stuck and I'm thinking "This really shouldn't be that
hard."
So, rebasing (rebaseall'ing) the cygwin system as outlined in the
datahammer blog entry (along with the ash advice of the pychallenge
article) still doesn't seem to be enough to get a clean build.
I think this is an issue that probably needs to be addressed by PIL
maintainers that fully understand the root of the problem (and it
should probably go in the PIL FAQ), but in the meantime does anyone
out there know how to get around this issue?
Thanks,
-ej
following article indicates. I first ran into the error message about
not being able to remap C:\cygwin\bin\tk84.dll to be the same address
as it's parent.
Using that information, Google helped me find this article:
http://blog.datahammer.info/2008/11/install-pil-under-cygwin-python-25.html
After following it's advice and running:
$ ./rebase -b 0x1000000000 tk84.dll
I was able to get the PIL build to proceed, but when it was done, it
said that there was no support built for Tk, and I then noticed that
basic Tkinter functionality was broken from the Python interpreter.
I went back to Cygwin setup, and had it reinstall the tcl/tk package,
and then Tkinter (import from the interactive interp.) got fixed.
Googling some more, I found this article (which implied datahammer
isn't quite right): http://www.pythonchallenge.com/forums/viewtopic.php?t=135
I ran /usr/bin/rebaseall (from ash)(and if you end up doing this
yourself, be aware that it takes a while - I was afraid that process
had hung and I was going to have to rebuild the whole Cygwin shooting
match from scratch, but it eventually completed (silently)).
After this, I checked that Tkinter still worked from Python (it did),
and then tore out the whole PIL directory (Imaging-1.1.6) I had tried
to install from before, re-extracted the tar file to get a clean
install directory, and then again attempted to build PIL. Now,
instead of getting the failure message about not being able to remap
the dll, the build just hangs:
$ python setup.py build_ext -i
running build_ext
building '_imaging' extension
creating build
creating build/temp.cygwin-1.5.25-i686-2.5
creating build/temp.cygwin-1.5.25-i686-2.5/libImaging
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-
prototypes -DHAVE_LIBJPEG -DHAVE_LIBZ -I/usr/include/freetype2 -
IlibImaging -I/usr/include -I/home/ej/python/PIL/jpeg-6b -I/usr/
include/python2.5 -c _imaging.c -o build/temp.cygwin-1.5.25-i686-2.5/
_imaging.o
<eventually hit CTRL-C to leave>
Now, I'm rather stuck and I'm thinking "This really shouldn't be that
hard."
So, rebasing (rebaseall'ing) the cygwin system as outlined in the
datahammer blog entry (along with the ash advice of the pychallenge
article) still doesn't seem to be enough to get a clean build.
I think this is an issue that probably needs to be addressed by PIL
maintainers that fully understand the root of the problem (and it
should probably go in the PIL FAQ), but in the meantime does anyone
out there know how to get around this issue?
Thanks,
-ej