Re: [Pythonmac-SIG] Someone had PIL trouble on i386 10.4.6 Python 2.4 IIRC--I succeeded this evening
Ronald Oussoren wrote: >>> I'll have to package up my package build script one of these days ;-) Did you ever package up your build script? > Its one level higher: a script that uses bdist_egg and bdist_mpkg to build > binary packages given a list of recipes. >> I like binary packages on > pythonmac.org, but don't like the fact that most of them seem to build > by hand and that some required manual prodding to get them to work. Me too, I've tweaked matplotlib one times to many, and now I can't figure out how to get fat static libs of the dependencies. It's time to get a script written that "just builds it" Anything you've got, I'll take! -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Someone had PIL trouble on i386 10.4.6 Python 2.4 IIRC--I succeeded this evening
On 20-apr-2006, at 0:53, Christopher Barker wrote: > Bob Ippolito wrote: >> The libs should all be statically linked to the extensions, they >> shouldn't be separate in the installer. > > Ronald Oussoren wrote: >> I'd prefer to have fully self contained packages, and preferably >> eggs at that. Having a shared libary makes it *harder* to >> independendly >> update extensions using libpng or libfreetype. > > No one answered my question directly, but both Bob and Ronald have > spoken: > > It's better for each package to statically link any libs it needs > (unless Apple provides them), even though that means that a given > python > program may well end up using three copies of the same lib. > > Just to be totally clear: Is there any problem with the same program > using three slightly different versions of the same lib? Thanks to two-level namespaces that shouldn't be a problem unless two extensions share datastructures from a library. An example of this are the curses and panel extensions in the stdlib, both link to libcurses and they share datastructures from curses. You'll see a hard crash when those extensions are staticly linked to curses. > >> I'll have to package up my package build script one of these days ;-) > > What does it do? Something different than bdist_mpkg ? Its one level higher: a script that uses bdist_egg and bdist_mpkg to build binary packages given a list of recipes. That makes it a lot easier to tweak the build process or rebuild packages when the libraries they use are changed. Its the result of a pet peeve: I like binary packages on pythonmac.org, but don't like the fact that most of them seem to build by hand and that some required manual prodding to get them to work. Ronald ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Someone had PIL trouble on i386 10.4.6 Python 2.4 IIRC--I succeeded this evening
Daniel Lord wrote: > That sound reasonable, but not what I did--I installed them in /usr/ > local/lib & include. I've done that, but the only way I could make sure that they got statically linked was to make sure that there were not dynamic versions of the same libs anywhere else on the search path, so I found it easier to put them in a special place, and it's always possible that I'd have the dynamic libs installed for some other reason. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Someone had PIL trouble on i386 10.4.6 Python 2.4 IIRC--I succeeded this evening
On Apr 19, 2006, at 15:53, Christopher Barker wrote: > Bob Ippolito wrote: >> The libs should all be statically linked to the extensions, they >> shouldn't be separate in the installer. > > Ronald Oussoren wrote: >> I'd prefer to have fully self contained packages, and preferably >> eggs at that. Having a shared libary makes it *harder* to >> independendly >> update extensions using libpng or libfreetype. > > No one answered my question directly, but both Bob and Ronald have > spoken: > > It's better for each package to statically link any libs it needs > (unless Apple provides them), even though that means that a given > python > program may well end up using three copies of the same lib. > > Just to be totally clear: Is there any problem with the same program > using three slightly different versions of the same lib? NOt as far as I can tell--the libraries are statically linked so don't even need to be on the platform after that. > >> I'll have to package up my package build script one of these days ;-) > > What does it do? Something different than bdist_mpkg ? By build I by hand: curl, patch code by hand, make; sudo make install. The libs need their make components patched to compile FAT binaries and PIL needed to be patched to find the .a files to link into its binaries. And freetype uses a confusing Jam-based install which had me searching for where to change it. > > Daniel Lord wrote: >> I built Universal jpeg-6b, freetype2, and zlib for my current project >> of Universal PIL. I can add libpng in easily so I'll do it. >> So that makes jpeg, png, freetype, and zlib. What else? > > Those are the ones I need at the moment. Thanks! I guess a zip archive > of the collection would be the best way to get it out there. I'll zip up the .a files and put them on my iDisk--will send you a URL when ready. > >> I have successfully packaged up a Universal PIL for 2.4 (thanks for >> the tips Bob;-). Packaged--not tested yet on PPC and Intel so I am >> closer to releasing it. > > Post a link to it here when you are ready so we can test it. Bob tested it and posted it already (see his email). More testing would be appropriate though. > Maybe it would be helpful to have a standard way to link static libs > with our packages. What I've done for matplotlib is create a > "StaticLibs" directory at the same level as the setup./py, then hacked > the setup.py to include it in the linking (and header) paths. That sound reasonable, but not what I did--I installed them in /usr/ local/lib & include. > > I'll probably create one that has all of the above libs in it, then I > can add a symlink to it for each package I'm trying to build. > > If anyone has any better ideas, I'd be glad to hear them. > > -Chris > > > > > -- > Christopher Barker, Ph.D. > Oceanographer > > NOAA/OR&R/HAZMAT (206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > [EMAIL PROTECTED] > ___ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Someone had PIL trouble on i386 10.4.6 Python 2.4 IIRC--I succeeded this evening
Bob Ippolito wrote: > The libs should all be statically linked to the extensions, they > shouldn't be separate in the installer. Ronald Oussoren wrote: > I'd prefer to have fully self contained packages, and preferably > eggs at that. Having a shared libary makes it *harder* to independendly > update extensions using libpng or libfreetype. No one answered my question directly, but both Bob and Ronald have spoken: It's better for each package to statically link any libs it needs (unless Apple provides them), even though that means that a given python program may well end up using three copies of the same lib. Just to be totally clear: Is there any problem with the same program using three slightly different versions of the same lib? > I'll have to package up my package build script one of these days ;-) What does it do? Something different than bdist_mpkg ? Daniel Lord wrote: > I built Universal jpeg-6b, freetype2, and zlib for my current project > of Universal PIL. I can add libpng in easily so I'll do it. > So that makes jpeg, png, freetype, and zlib. What else? Those are the ones I need at the moment. Thanks! I guess a zip archive of the collection would be the best way to get it out there. > I have successfully packaged up a Universal PIL for 2.4 (thanks for > the tips Bob;-). Packaged--not tested yet on PPC and Intel so I am > closer to releasing it. Post a link to it here when you are ready so we can test it. Maybe it would be helpful to have a standard way to link static libs with our packages. What I've done for matplotlib is create a "StaticLibs" directory at the same level as the setup./py, then hacked the setup.py to include it in the linking (and header) paths. I'll probably create one that has all of the above libs in it, then I can add a symlink to it for each package I'm trying to build. If anyone has any better ideas, I'd be glad to hear them. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Someone had PIL trouble on i386 10.4.6 Python 2.4 IIRC--I succeeded this evening
On 19-apr-2006, at 22:27, Daniel Lord wrote: > > On Apr 19, 2006, at 13:04, Ronald Oussoren wrote: > >> I'll post the script I'm using to build universal packages this >> weekend. >> I have recipes for the software I'm using and several other. That >> includes >> PIL (including jpeg, tif and freetype support). > I'll put mine on my iDisk and send you a link. I'd like to see your > scripts since I did it by hand and recorded it with bash > typescript--to later script it using sed for the text editing. I > have a Macbook Pro and PPC will be happy to test things. I have a python script that's derived from the script that I'm using to build the univeral python distribution. > >> It is actually not very hard to build univeral libraries for most >> software. > Yeah, if *I* can do it it cannot be too arcane ;-) It can be pretty involved. If you're very unlucky you'll have to build a ppc and intel version version of software and then merge them using lipo. Luckily most python-related software I've run into until now can be coaxed into building using 'cc -arch ppc -arch i386' as the compiler. Ronald ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Someone had PIL trouble on i386 10.4.6 Python 2.4 IIRC--I succeeded this evening
On Apr 19, 2006, at 13:04, Ronald Oussoren wrote:I'll post the script I'm using to build universal packages this weekend. I have recipes for the software I'm using and several other. That includes PIL (including jpeg, tif and freetype support).I'll put mine on my iDisk and send you a link. I'd like to see your scripts since I did it by hand and recorded it with bash typescript--to later script it using sed for the text editing. I have a Macbook Pro and PPC will be happy to test things. It is actually not very hard to build univeral libraries for most software.Yeah, if *I* can do it it cannot be too arcane ;-) I'd really prefer to ship addon packages as standalone eggs. AgreedDaniel___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Someone had PIL trouble on i386 10.4.6 Python 2.4 IIRC--I succeeded this evening
On 19-apr-2006, at 18:49, Christopher Barker wrote: > Bob Ippolito wrote: >> *ALWAYS* prefer convenience over space. Never make separate >> distributions for i386 and PPC. Simplicity is key. > > Absolutely. > >> I will no longer accept single-architecture packages for >> pythonmac.org/packages except under special circumstances > > However... Right now, we don't have Universal packages for most > things. > This creates a difficult situation for folks, particularly those on > Intel Macs. It is a serious challenge to build Universal packages, at > least for those packages that rely on third party libs (PIL, > Matplotlib, > wxPython) I'll post the script I'm using to build universal packages this weekend. I have recipes for the software I'm using and several other. That includes PIL (including jpeg, tif and freetype support). > About those libs: > > As it is a challenge to build universal libs, and a bunch of common > python packages require the same libs, I'd love to see a repository of > Universal libs for use with Python packages. It is actually not very hard to build univeral libraries for most software. I'd really prefer to ship addon packages as standalone eggs. > > My suggestion: > > A ExtraLibs.mpkg, right there with the packages on pythonmac.org that > includes Universal shared libs required by some common packages. They > could perhaps be installed in the Python Framework, so they won't > interfere with anything else. > > a) is this possible? yes > b) is this a good idea? no. This is an arbitrary selection of libraries, why these and not others? Ronald ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Someone had PIL trouble on i386 10.4.6 Python 2.4 IIRC--I succeeded this evening
On Apr 19, 2006, at 9:49, Christopher Barker wrote: > My suggestion: > > A ExtraLibs.mpkg, right there with the packages on pythonmac.org that > includes Universal shared libs required by some common packages. They > could perhaps be installed in the Python Framework, so they won't > interfere with anything else. > > a) is this possible? > b) is this a good idea? > > I suggest the following libs: > > libfreetype > libpng > libjpeg > > Other common ones? I built Universal jpeg-6b, freetype2, and zlib for my current project of Universal PIL. I can add libpng in easily so I'll do it. So that makes jpeg, png, freetype, and zlib. What else? On the other topic... I have successfully packaged up a Universal PIL for 2.4 (thanks for the tips Bob;-). Packaged--not tested yet on PPC and Intel so I am closer to releasing it. However, it isn't including the libs so I am studying py2app and bdist_mpkg nuances to figure out how to package them all in one installer. Once I get this done, I'll post it the instructions for hand building in the wiki and the all-in-one plus a separate Universal libs package on my iDisk. I am also trying to see if I can make a quick and dirty shell script using curl, sed, and toehr tools to create a one-button build and install but that is after the above. ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Someone had PIL trouble on i386 10.4.6 Python 2.4 IIRC--I succeeded this evening
Bob Ippolito wrote: > *ALWAYS* prefer convenience over space. Never make separate > distributions for i386 and PPC. Simplicity is key. Absolutely. > I will no longer accept single-architecture packages for > pythonmac.org/packages except under special circumstances However... Right now, we don't have Universal packages for most things. This creates a difficult situation for folks, particularly those on Intel Macs. It is a serious challenge to build Universal packages, at least for those packages that rely on third party libs (PIL, Matplotlib, wxPython) Until those folks with the skills to do it find the time to build some of the most common ones, I'm not sure it's such a bad idea to have a repository for i386 and PPC-only packages. About those libs: As it is a challenge to build universal libs, and a bunch of common python packages require the same libs, I'd love to see a repository of Universal libs for use with Python packages. My suggestion: A ExtraLibs.mpkg, right there with the packages on pythonmac.org that includes Universal shared libs required by some common packages. They could perhaps be installed in the Python Framework, so they won't interfere with anything else. a) is this possible? b) is this a good idea? I suggest the following libs: libfreetype libpng libjpeg Other common ones? -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Someone had PIL trouble on i386 10.4.6 Python 2.4 IIRC--I succeeded this evening
Chris, I will do that but as it stands, one has to build this on the system it is going to run on, i.e. i386. I assume, but haven't gotten around to trying to build this on my PPC system since there is a valid build for that already. First, I am going to create a package for this for i386-based Macs and see if I can write a script to do the whole thing 'auto- magically'. Then I'll write the instructions up. Which leads me to a philosophical question for the community: which makes since for things like this as a standard practice for distribution (ranging from hardest to easiest) 1) to create a package with copies of the libraries used as Universal 'FAT' binaries (zlib, freetype2, jpeg-6b) not to mention PIL as well that will install correctly for PPC or i386 systems but include useless binary versions and take up space, 2) have two separate 'chunks' and have the installer select one based on the installation platform, or 3) just provide two separate packages--one for i386 and one for PPC? Daniel On Apr 18, 2006, at 13:22, Christopher Barker wrote: > Daniel, > > It would be great if you could post this summary to: > > http://pythonmac.org/wiki/UniversalPackages > > thanks, -Chris > > > > -- > Christopher Barker, Ph.D. > Oceanographer > > NOAA/OR&R/HAZMAT (206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > [EMAIL PROTECTED] ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Someone had PIL trouble on i386 10.4.6 Python 2.4 IIRC--I succeeded this evening
Kevin Walzer wrote: > Is a universal package of Tcl/Tk (for Tkinter apps) something that > others would find useful? Isn't it part of the new Universal build? If not, then yes, please do contribute it. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Someone had PIL trouble on i386 10.4.6 Python 2.4 IIRC--I succeeded this evening
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christopher Barker wrote: > Daniel, > > It would be great if you could post this summary to: > > http://pythonmac.org/wiki/UniversalPackages > > thanks, -Chris > > > Is a universal package of Tcl/Tk (for Tkinter apps) something that others would find useful? I'm putting together one for my own purposes and would be glad to contribute it (or post a download link) when it's ready. - -- Kevin Walzer Poetic Code http://www.kevin-walzer.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFERU1ZrTC5hIgjqTMRAlg9AJ90ibOdJM+S+/cQSW2qz1rDRtXFGACeKVtt HiHr+bbPqhdiUyJNXjx4iXI= =TiEN -END PGP SIGNATURE- ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Someone had PIL trouble on i386 10.4.6 Python 2.4 IIRC--I succeeded this evening
Daniel, It would be great if you could post this summary to: http://pythonmac.org/wiki/UniversalPackages thanks, -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Someone had PIL trouble on i386 10.4.6 Python 2.4 IIRC--I succeeded this evening
I was able to successfully compile and install it with just a few tweaks on my Macbook Pro this evening. I don't know if this newbies methods are optimal, but they seem to have worked finally (I tried straight 'out of the box' compiles which failed at first) [EMAIL PROTECTED] sudo python setup.py build_ext -i gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -g -bundle -undefined dynamic_lookup -flat_namespace -no-cpp-precomp build/temp.macosx-10.4-fat-2.4/_imagingtk.o build/temp.macosx-10.4- fat-2.4/Tk/tkImaging.o -L/Library/Frameworks/Python.framework/ Versions/2.4/lib -L/usr/local/lib -L/usr/lib -o PIL/_imagingtk.so - framework Tcl -framework Tk *** lines removed *** PIL 1.1.5 BUILD SUMMARY version 1.1.5 platform darwin 2.4.3 (#1, Apr 7 2006, 10:54:33) [GCC 4.0.1 (Apple Computer, Inc. build 5250)] --- TKINTER support ok --- JPEG support ok --- ZLIB (PNG/ZIP) support ok --- FREETYPE2 support ok To check the build, run the selftest.py script. [EMAIL PROTECTED] python selftest.py 55 tests passed. SUCCESS! Here is what I did: I installed four things: 1. zlib: a straight forward curl, tar zxvf, ./configure, make, sudo make install curl http://www.gzip.org/zlib/zlib-1.1.4.tar.gz -o zlib-1.1.4.tar.gz 2. freetype: DL from SourceForge and straight forward tar zxvf, ./ configure, make, sudo make install 3. jpeg-6b: this is where the trouble started. curl http://www.ijg.org/files/jpegsrc.v6b.tar.gz -o jpegsrc.v6b.tar.gz a. after untarring and running ./configure, open 'Makefile' and change one line: CFLAGS= -O2 -no-cpp-precomp -I$(srcdir) to CFLAGS= -arch i386 -O2 -no-cpp-precomp -I$(srcdir) then 'make; sudo make install' b. then we have to put some manifest files the the lib in the right place to be found by PIL's build setup.py (I chose /usr/local) sudo cp jconfig.h jmorecfg.h jpeglib.h /usr/local/include sudo cp libjpeg.a /usr/local/lib sudo ranlib /usr/local/lib/libjpeg.a 4. PIL: this required some tweaking per instructions given in the setup.py to find the jpeg lib and manifests. curl http://effbot.org/downloads/Imaging-1.1.5.tar.gz -o Imaging-1.1.5.tar.gz a. bascially, change JPEG_ROOT = None to JPEG_ROOT = "(/usr/local/lib,/usr/local/include)" then 'sudo python setup.py build_ext -i' And success follows--at least for me ;-) ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
