Python and PIL and rebase, oh my!

Python and PIL and rebase, oh my!

[Charles Wilson]

[-- Attachment #1: Type: text/plain, Size: 5041 bytes --]

<<< Don't try this unless you really know what you're doing... >>>

I was able to get PIL compiled on cygwin, using the EXISTING, official 
cygwin tk/tcl port -- not Mumit Khan's version.  Here's what I did (but 
it led to some discussion points, below):

#1) grabbed the various include files from the naked-tk CVS repo on 
sourceware, and put them into /usr/include/tk/* and 
/usr/include/tk/X11/*.  You can (temporarily) get them here:
http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/tk-includes.tar.bz2

#2) downloaded the PIL 1.1.3 archive, unpacked it

#3) applied the attached patch

#4) fixed up some symlinks:
   cd  /usr/lib
   ln -s libtk80.a libtk8.0.a
   ln -s libtcl80.a libtcl8.0.a

#5) rebased a bunch of DLLs using Jason's rebase tool (more on that, later):

rebase -d -b 0x68000000 -o 0x10000 cygXpm-X4.dll cygXpm-noX4.dll \
     cygbz21.0.dll cygbz2-1.dll cygform5.dll cygform6.dll \
     cyggdbm.dll cyghistory4.dll cyghistory5.dll cygintl.dll \
     cygitcl30.dll cygitk30.dll cygjbig1.dll cygjpeg6b.dll cygmenu5.dll \
     cygmenu6.dll cygncurses++5.dll cygncurses++6.dll cygncurses5.dll \
     cygncurses6.dll cygpanel5.dll cygpanel6.dll cygpcre.dll \
     cygpcreposix.dll cygpng2.dll cygpng10.dll cygreadline4.dll \
     cygreadline5.dll cygregex.dll cygssl.dll cygtcl80.dll \
     cygtclreg80.dll cygtiff3.dll cygtk80.dll cygz.dll \
     /usr/lib/python2.2/lib-dynload/*.dll \
     /usr/lib/python2.2/site-packages/*.dll

#6) Followed the instructions to build and install PIL

#7) rebased again, but this time including the PIL dll's:
rebase -d -b 0x68000000 -o 0x10000 cygXpm-X4.dll cygXpm-noX4.dll \
     cygbz21.0.dll cygbz2-1.dll cygform5.dll cygform6.dll \
     cyggdbm.dll cyghistory4.dll cyghistory5.dll cygintl.dll \
     cygitcl30.dll cygitk30.dll cygjbig1.dll cygjpeg6b.dll cygmenu5.dll \
     cygmenu6.dll cygncurses++5.dll cygncurses++6.dll cygncurses5.dll \
     cygncurses6.dll cygpanel5.dll cygpanel6.dll cygpcre.dll \
     cygpcreposix.dll cygpng2.dll cygpng10.dll cygreadline4.dll \
     cygreadline5.dll cygregex.dll cygssl.dll cygtcl80.dll \
     cygtclreg80.dll cygtiff3.dll cygtk80.dll cygz.dll \
     /usr/lib/python2.2/lib-dynload/*.dll \
     /usr/lib/python2.2/site-packages/*.dll \
     /usr/lib/python2.2/site-packages/PIL/*.dll

#8) ran the self-tests, it worked.  viewer.py also worked...very impressive.

---------------------------------------------------------------------------
Discussion:

#1)  ------------------------------
About programs that can exist both in an X- version and a "native" 
version.  I've found one...tk!  So, I dismissed Earnie's concerns about 
this issue with a "bring it up when we actually have a problem".  Guess 
what...

You've got tcl/tk, whose headers include "X11/Xlib.h" and such -- but 
the cygwin-tcl/tk versions of those standard X headers are NOT the 
"real" X versions.  They seem to be fake.  (kinda like the include files 
shipped with xpm-nox).  Now, you can't build a tk-based program on 
cygwin currently -- because our cygwinized tk.h #includes X11/Xlib.h, 
but doesn't really WANT the true Xlib.h from XFree86...and our tk 
package doesn't ship the cygwinized tk versions.

So, we need to ship the various supporting include files for cygwin's 
tcl/tk packages -- but they cannot go into /usr/include(/X11) because 
officially, that's where the "real" X11 #include files go.  Sigh.

And, of course, it's always possible somebody will come along and build 
a "real" tcl/tk package that uses X...

This conundrum now has me leaning toward Earnie's position: X-linked 
apps need to have --prefix=/usr/X11R6 precisely so that their libraries 
and include files go under /usr/X11R6 and not /usr.


#2) ------------------------------
Given that, I have a 3 requests for the tcl/tk maintainer:
   1) for the next release, can we have the header files (other than 
just tk.h) installed as well?  (Where?  I dunno... /usr/include/tk/ & 
/tcl/?)
   2) can we have a postinstall script that links
   /usr/lib/libtclX.Y.a ---> libtclXY.a
   /usr/lib/libtkX.Y.a  ---> libtkXY.a
   3) please make sure the tkConfig.sh and tclConfig.sh files are 
correct.  The current versions include lots of references to 
/cygnus/netrel/src/gdb-20001125-1/  etc.  That's bad...

#3) ------------------------------
rebase:  We really need to get this into setup ASAP.  The current 
version (as posted on the mailing list) has the following interesting 
property:
$ cygcheck rebase.exe
Found: .\rebase.exe
.\rebase.exe
   D:\cygwin\bin\cygwin1.dll
     D:\WINNT\System32\KERNEL32.dll
       D:\WINNT\System32\NTDLL.DLL
   D:\WINNT\System32\IMAGEHLP.DLL
     D:\WINNT\System32\MSVCRT.DLL

I dunno about you, but depending on both cygwin1.dll and MSVCRT.dll 
bothers me.  But, we need IMAGEHLP.DLL -- so rebase.exe has to be a 
mingw app.  There's only one problem: it calls 
cygwin_conv_to_win32_path.  Now, I know the setup codebase includes its 
own versions of those functions, so that'd probably help wean rebase.exe 
away from cygwin1.dll...

--Chuck

[-- Attachment #2: Imaging-1.1.3.patch --]
[-- Type: text/plain, Size: 617 bytes --]

diff -urN -x build Imaging-1.1.3-orig/setup.py Imaging-1.1.3/setup.py
--- Imaging-1.1.3-orig/setup.py	Thu Mar 14 14:55:04 2002
+++ Imaging-1.1.3/setup.py	Thu May  9 17:36:17 2002
@@ -40,7 +40,7 @@
 
 MODULES = []
 
-INCLUDE_DIRS = ["libImaging"]
+INCLUDE_DIRS = ["libImaging", "/usr/include/tk"]
 LIBRARY_DIRS = ["libImaging"]
 LIBRARIES = ["Imaging"]
 
@@ -117,7 +117,7 @@
 except (ImportError, AttributeError):
     pass
 else:
-    INCLUDE_DIRS = ["libImaging"]
+    INCLUDE_DIRS = ["libImaging", "/usr/include/tk"]
     LIBRARY_DIRS = ["libImaging"]
     LIBRARIES = ["Imaging"]
     if sys.platform == "win32":


[-- Attachment #3: Type: text/plain, Size: 214 bytes --]

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Python and PIL and rebase, oh my!

[Jason Tishler]

On Thu, May 09, 2002 at 06:39:39PM -0400, Charles Wilson wrote:
> #3) ------------------------------
> rebase:  We really need to get this into setup ASAP.

I know, I know... [Hangs head in shame again.]  Sigh...

> The current 
> version (as posted on the mailing list) has the following interesting 
> property:
> $ cygcheck rebase.exe
> Found: .\rebase.exe
> .\rebase.exe
>   D:\cygwin\bin\cygwin1.dll
>     D:\WINNT\System32\KERNEL32.dll
>       D:\WINNT\System32\NTDLL.DLL
>   D:\WINNT\System32\IMAGEHLP.DLL
>     D:\WINNT\System32\MSVCRT.DLL
> 
> I dunno about you, but depending on both cygwin1.dll and MSVCRT.dll 
> bothers me.  But, we need IMAGEHLP.DLL -- so rebase.exe has to be a 
> mingw app.

Oops!

> There's only one problem: it calls 
> cygwin_conv_to_win32_path.  Now, I know the setup codebase includes its 
> own versions of those functions, so that'd probably help wean rebase.exe 
> away from cygwin1.dll...

Actually, I have had a Mingw version of this stand-alone version of
rebase.exe for a while.  I just uploaded it to my web site:

    http://www.tishler.net/jason/software/rebase/

and moved the (deprecated) Cygwin version to:

    http://www.tishler.net/jason/software/rebase/deprecated/

Now that I can use STL in Cygwin's setup.exe, I'm hoping to start making
head way with rebase/setup.exe integration.

Jason

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/