Re: [Pythonmac-SIG] The Universal Buld and py2app
Did you check out the trunk, or the maintenance branch? The trunk is not usable. http://svn.red-bean.com/bob/py2app/branches/py2app-0.2-maint/ I did use the maintenance branch. Sorry, should have specified. Also, you probably shouldn't use Python 2.3.5 as shipped on intel macs. It's got some known bugs (endian and otherwise) and is old, use the 2.4 universal build: http://pythonmac.org/packages/py24-fat/ I tried this version when I was struggling to get PyQt to work. However, I couldn't get sip-4.4.1 to work properly with this version. It compiled just fine, but whenever you tried to import the sip moduled (ie. when PyQt is configured), it fails with the message: ImportError: Inappropriate file type for dynamic loading I asked on the PyKDE mailing list, and I was that something in the flags you use makes it give that error, and that compiling from source (enabling framework, make framework install) should fix it. Unfortunately, I got an error when I tried compiling from source: /usr/bin/ld: warning Python.framework/Versions/2.4/Python cputype (18, architecture ppc) does not match cputype (7) for specified -arch flag: i386 (file not loaded) /usr/bin/ld: Undefined symbols: _PyMac_Error _Py_Main collect2: ld returned 1 exit status It looks like this is due to ppc being specified somewhere. I didn't see an easy to way to tell configure that I wanted i386 instead of ppc. Is there a flag I can pass to the configure script, or do I have to do a CFLAGS=-arch i386 and CXXFLAGS='-arch i386'? And how do I make this a universal app? Thanks for your help, Adam ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Compiling Numeric for OSX-intel
I posted earlier on building Numeric on a MacBook Pro with the latest Universal build of python, installed via pkg. Similar problems have arisen with compiling other packages. I believe distutils to be at fault. The problem is the -lcc_dynamic flag invoked on gcc. During the build process whenever it threw an error I went back and reinvoked gcc with that flag removed, and it compiled fine, then continued with setup.py build; after several fixes of this sort the job completed, I installed it, and everything appears to work as expected. I'm not a distutils expert so I'm not sure where this flag is stored or what it means or how to prevent it being invoked. I think somehow the python which I installed (from http://pythonmac.org/packages/py24-fat/index.html) was compiled with this flag coded in, and it doesn't work on my MacBook. Perhaps it's a matter of a different architecture or a different setup, I don't know. I can't even find a cc_dynamic library file that it would link to. The same thing happened whether or not /usr/local/lib/libcc_dynamic.a is absent or is symlinked to /usr/lib/gcc/i686-apple-darwin8/4.0.1/libgcc.a. But it doesn't seem to be necessary on my machine, and thus I think python2.4-fat should be altered to incorporate this. It should be noted that I experienced similar problems with other packages besides Numeric. Jeremy___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Apple Tutorial on building Universal binaries from Open Source
This is fairly simple and uses Xcode, but really all Xcode is in this case is a wrapper for the shell scripts.I am going to try it with just commandline tools and scripts. Should work fine.http://developer.apple.com/opensource/buildingopensourceuniversal.htmlThe references at the end are good sources of more detailed info. These should help a lot of people in their struggles:Adopting Universal Binaries on Mac OS XUniversal Binary Programming GuidelinesPorting UNIX/Linux Applications to Mac OS XGCC Porting GuideThe GNU Compiler Collection on Mac OS XTechnical Note TN2137: Building Universal Binaries from configure-based Open Source Projects Daniel Lord[EMAIL PROTECTED]---"You will never regret getting up too early,and you'll always regret getting up too late,but sometimes you may regret giving up too late." -- Mountaineer's Adage ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] multi-platform Python distributions question
Mark and Chris, thanks for your interest. Here's some in-depth info about my project. I've designed a desktop applet that displays custom artwork and interface elements, and incorporates a modified calendar control from the wxPython demo as a basis for its calendar grid implementation. Basically this applet is intended to mimic to some degree an ink-on-paper wall calendar of the variety that usually uses themed graphics as decorations. The applet is initially to be used to display artwork produced by members of an artists' web community I frequent, conceptart.org, but can be adapted to display any graphics that can be modulized with image2py. The interface artwork is also so modulized, so that can also be easily customized. The applet is designed to adjust itself to any size and aspect ratio of art, within reasonable limits (even unreasonable if the artwork is properly modified for inclusion), with partially-fixed-size regions dedicated to the UI. Currently, to avoid the need for complex graphics code for resampling and scaling the artwork, the displayed artwork is fixed in scale, with no allowance for dynamic adaptation to monitor size. Artwork modules for different screen resolutions are the alternate solution, a bit inelegant in terms of coding but better for proper display of the art, which is the driving purpose for the calendar applet. The applet windows cannot be dynamically resized, for much the same reason. There is functionality for marking and adding short text notes to selected dates on the calendar control, which is accessed on user demand. The applet is designed to be platform non-specific, using borderless or simple-border frames and avoiding as much as possible platform dependencies in terms of interface controls, which are very rudimentary. In its current implementation, there are no user menus, and only three main interface buttons -- Close, Minimize, and Open Calendar Grid. A TaskBarIcon provides user control as well, for Close, Minimize and Restore commands. The calendar control itself employs the date navigation functions from the wxPython demo (calendar window version), with modified date marking code, and new code to permit input, recording and reading w/output of the date-selective text notes. Two pickled text files with custom (though rather simple) formatting rules are used for persistent data: the calendar text notes and the closing position of the applet. I've only been using Python since the first of this month, so I've depended heavily on adaptation of existing modules when feasible, drawing mainly from the wxPython GUI library. Originality is in the interface design and its visual character, in the scripting to maintain the frames hierarchy the visual design requires, and in the date marking functions added to (or modified from) the calendar control. Distribution of the applet will be international and multi-platform, reflecting the wide member base of conceptart.org. An informal survey has already identified Win98, WinXP (home and Pro), Mac OSX 10.3.9 and above, and Debian Linux as platforms in use by the members, so I need some assistance in prepping distribution packages that do not require separate installations of Python 2.4 and wxPython 2.6 Unicode (though the Win98 version will likely be wxPython ANSI). So far I've done successful test builds for the WinXP and Win98 platforms using py2exe. Since I am primarily a CG artist, I don't maintain multi-platform systems for my programming efforts (which in the past have included TcL-based plugins and RealBasic standalones for Mac OS 9.x, and UnrealScript for game-specific coding on Windows), so instead I'm seeking the assistance of interested Python community members. I chose Python as the implementing code base because my research indicated it is very flexible, has a respectable documentation database (essential for a novice such as I), and is very similar in syntax and abstract structure to the other scripting languages I've used. The applet is to be distributed free of charge, as a vehicle for promoting contributing artists from conceptart.org. Contributors to the packaging efforts will of course be credited if so desired. My current functionality status is unreleased beta; my plans are to release the beta for testing by the end of April. Beta testers will be chosen primarily from the conceptart.org membership, the initial target audience for the applet, but I would of course welcome feedback from the Python community as well. I hope that answers most questions. I can provide URLs to forum threads on conceptart.org that have some details about the look of the beta if that is of further interest. chip - Original Message - From: Christopher Barker [EMAIL PROTECTED] To: chip nyman [EMAIL PROTECTED] Sent: Tuesday, April 25, 2006 7:09 PM Subject: Re: [Pythonmac-SIG] multi-platform Python distributions question chip nyman wrote: I have a small
[Pythonmac-SIG] GMP bigot now chastened.
Alex, Just so you and anyone who cares that our platform get fair treatment know. Turns out the Mac bigot was behaving badly again. GMP 4.2 doesn't compile on PPC macs either and he was blaming Apple's compilers. Turns out we figured out a fix involving PIC--it seems Linux PPCs have the same problem. So it was gcc problem not an Apple one. I called him on and asked that he fix the site to avoid further embarassment ( i did that privately) but I publicly asked him to include the patches for Apple i386 and PPC in the source and wondered why they hadn't been adopted. That struck a nerve so he set my mail address to be moderated effectively quarantining me to stifle me. I figured this would happen and I didn't care--I got in a few licks and he's made a fool of himself. He took down the diatribe against Apple at least. In my life experience, I have found that appeasing such ignorant fools drunk with power only encourages them. It was a good fight, I accomplished what I wanted, and I feel no loss with the gmp list--I really only want it to work. On Apr 22, 2006, at 9:50, Alex Martelli wrote: On Apr 22, 2006, at 1:59 AM, [EMAIL PROTECTED] wrote: No arbitrary precison math on Mac-tel say it ain't so! It ain't so. The analog of a single gene pool in nature has come to pass for arbitrary precison math (APM) for OS X (native not Python). GMP is 'it' for APM as far as I can tell unless I want to write my own. I believe intel also has libraries (they offered them for beta at some point, but I didn't follow through on that), but that's not the key point. And GMP doesn't compile on Mac-tel and won't for some time: The current release is 4.2, released 2006-03-26. It fixes all bugs found in 4.1.4, as well as several portability problems. It also adds several new features. Note that we chose not to work around all new GCC bugs in this release. Never forget to do a make check after building the library to make likely it was not miscompiled! Issues with GMP 4.2: Miscompilation on several platforms using several different compilers. Remember to run make check! GMP does not build on MacInteltoch machines. Since Apple uses their own, creative assembly syntax, it is not trivial to fix this. Nope. The current maintainer of GMP is apparently Apple-hostile AND by his own admission no expert on autoconf/libtools and similar blackmagic -- and apparently unable to admit it when he's dead wrong. Apple's assembly syntax is totally irrelevant here. The reason make check fails is Apple's creative *ld semantics*: an object file inside a library file is NOT brought in if the only symbols it satisfies are DATA ones. Make check makes an executable with unresolved symbols because of this strange optimization in Apple's ld (I dimly remember from the past other linkers with this kind of strangeness), that's all. Enrico Franchi posted to gmp-bugs, two weeks ago, a patch to gmp 4.2 which I had sent him -- it's a TINY patch (aparts from comments explaining why it exists, it's just *THREE* bedraggled lines...!!!): http://swox.com/list-archives/gmp-bugs/attachments/20060407/f364005b/ patch-0001.obj GMP's maintainer rejected it as THis is a too ugly patch for inclusion in GMP. (!!!). Anyway, download and apply that patch, and make check passes with flying colors. Then, I had the deadline for the 2nd ed of the Nutshell, then a week's vacation at the Grand Canyon, and have been catching up on things, so I haven't done any further followthrough - yet. Once this idiocy is solved, there is another problem: I STILL can't link gmpy.so beause I can't make libgmp.a to build properly for linkage into a -bundle. Specifically (with gmpy.sf.net's current CVS contents): brain:~/alex/gmpy alex$ python setup.py build_ext -i running build_ext building 'gmpy' extension creating build/temp.macosx-10.4-fat-2.4 creating build/temp.macosx-10.4-fat-2.4/src gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk - fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd - fno-common -dynamic -DNDEBUG -g -O3 -I./src -I/usr/local/include -I/ Library/Frameworks/Python.framework/Versions/2.4/include/python2.4 -c src/gmpy.c -o build/temp.macosx-10.4-fat-2.4/src/gmpy.o gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -g -bundle -undefined dynamic_lookup build/temp.macosx-10.4-fat-2.4/src/ gmpy.o -L/usr/local/lib -lgmp -o gmpy.so /usr/bin/ld: for architecture i386 /usr/bin/ld: /usr/local/lib/libgmp.a(add_n.o) has local relocation entries in non-writable section (__TEXT,__text) /usr/bin/ld: for architecture ppc /usr/bin/ld: warning /usr/local/lib/libgmp.a archive's cputype (7, architecture i386) does not match cputype (18) for specified -arch flag: ppc (can't load from it) collect2: ld returned 1 exit status lipo: can't open input file: /var/tmp//ccGbVJa4.out (No such file or directory) error: command 'gcc' failed
[Pythonmac-SIG] PIL 1.1.5 universal package currently broken
It seems that the PIL build is missing freetype *and* it's not even linked to a dynamic version of it. Very strange. import _imagingft Traceback (most recent call last): File stdin, line 1, in ? ImportError: Failure linking new module: /Library/Frameworks/ Python.framework/Versions/2.4/lib/python2.4/site-packages/PIL/ _imagingft.so: Symbol not found: _FT_New_Face Referenced from: /Library/Frameworks/Python.framework/Versions/2.4/ lib/python2.4/site-packages/PIL/_imagingft.so Expected in: flat namespace $ otool -L /Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/site-packages/PIL/_imagingft.so /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site- packages/PIL/_imagingft.so: /usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version 47.1.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.3) ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] GMP bigot now chastened.
On Apr 26, 2006, at 8:19 PM, Daniel Lord wrote: Alex, Just so you and anyone who cares that our platform get fair treatment know. Turns out the Mac bigot was behaving badly again. GMP 4.2 doesn't compile on PPC macs either and he was blaming Apple's compilers. Turns out we figured out a fix involving PIC--it seems Linux PPCs have the same problem. So it was gcc problem not an Apple one. I called him on and asked that he fix the site to avoid further embarassment ( i did that privately) but I publicly asked him to include the patches for Apple i386 and PPC in the source and wondered why they hadn't been adopted. That struck a nerve so he set my mail address to be moderated effectively quarantining me to stifle me. I figured this would happen and I didn't care--I got in a few licks and he's made a fool of himself. He took down the diatribe against Apple at least. In my life experience, I have found that appeasing such ignorant fools drunk with power only encourages them. It was a good fight, I accomplished what I wanted, and I feel no loss with the gmp list--I really only want it to work. Wow, thanks for the update -- that [[expletive deleted]] maintainer is most definitely doing GMP no favors (nor, any favors to the cause of open source, either). So, I guess, eventually we'll have to fork GMP, or something:-(. Ah well -- so the next minor 4.2.* is expected to build well -with- ppc on Mac both intel and PPC...? Thanks for your efforts, in any case! Alex ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
