🌐 Mailman 3 November 2001 - Pythonmac-SIG - python.org

Re: Pythonmac-SIG digest, Vol 1 #894 - 7 msgs
by Dan Wolfe Nov. 11, 2001

Nov. 11, 2001

On Sunday, November 11, 2001, at 09:01 AM, pythonmac-sig- request(a)python.org wrote: > On Saturday, November 10, 2001, at 10:20 PM, Just van Rossum wrote: >> I'd like to learn more about it: right now I know zip about packages. >> It would >> be really nice to have a .pkg that installs UnixPython 2.1.1 >> (especially now >> that it doesn't build anymore under 10.1...). > > I can build 2.1.1 fine under 10.1 (on a UFS partition) using: > > env LDFLAGS='-flat_namespace' OPT='-no-cpp-precomp' \ > ./configure --with-dyld > make > make test > sudo make install > > Have I missed something? a few things... Namely most people are running HFS+, have a limited stack space, have an old ncurses version, etc. Here's the recipe that I use to build it... note that I muck with the makefile vs using environmentals... which have an annoying tendency to be forgotten several days later. The patches are for a) dylibs --> allow zlib to be found, b) prevent ncurses from building. I have not pulled the patches for the thread redefine from the new 2.2 CVS repository (but it doesn't hurt anyone), nor have I fixed the fcntl case problem yet (haven't needed it - but it apparently it needs to be made part of the core Python vs dynamcially loaded)... :-( These patches should probably make it into Python 2.1.2.... Installed Python-2.1.1.tgz gnutar -xvzf Python-2.1.1.tgz apply the following patchs via % patch Python-2.1.1/Lib/distutils/unixccompiler.py unixccompiler.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/distutils/unixccompiler.py,v retrieving revision 1.35 retrieving revision 1.36 diff -c -r1.35 -r1.36 *** python/python/dist/src/Lib/distutils/unixccompiler.py 2001/07/16 14:46: 13 1.35 --- python/python/dist/src/Lib/distutils/unixccompiler.py 2001/08/27 15:08: 16 1.36 *************** *** 71,77 **** obj_extension = ".o" static_lib_extension = ".a" shared_lib_extension = ".so" ! static_lib_format = shared_lib_format = "lib%s%s" --- 71,78 ---- obj_extension = ".o" static_lib_extension = ".a" shared_lib_extension = ".so" ! dylib_lib_extension = ".dylib" ! static_lib_format = shared_lib_format = dylib_lib_format = "lib%s%s" *************** *** 259,264 **** --- 260,267 ---- for dir in dirs: shared = os.path.join( dir, self.library_filename(lib, lib_type='shared')) + dylib = os.path.join( + dir, self.library_filename(lib, lib_type='dylib')) static = os.path.join( dir, self.library_filename(lib, lib_type='static')) *************** *** 266,272 **** # data to go on: GCC seems to prefer the shared library, so I'm # assuming that *all* Unix C compilers do. And of course I'm # ignoring even GCC's "-static" option. So sue me. ! if os.path.exists(shared): return shared elif os.path.exists(static): return static --- 269,277 ---- # data to go on: GCC seems to prefer the shared library, so I'm # assuming that *all* Unix C compilers do. And of course I'm # ignoring even GCC's "-static" option. So sue me. ! if os.path.exists(dylib): ! return dylib ! elif os.path.exists(shared): return shared elif os.path.exists(static): return static apply the following patch via % patch Python-2.1.1/Lib/distutils/ccompiler.py ccompiler.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/distutils/ccompiler.py,v retrieving revision 1.39 retrieving revision 1.40 diff -c -r1.39 -r1.40 *** python/python/dist/src/Lib/distutils/ccompiler.py 2001/02/27 19:13:15 1.39 --- python/python/dist/src/Lib/distutils/ccompiler.py 2001/08/27 15:08:16 1.40 *************** *** 792,799 **** output_dir=''): if output_dir is None: output_dir = '' ! if lib_type not in ("static","shared"): ! raise ValueError, "'lib_type' must be \"static\" or \"shared\"" fmt = getattr (self, lib_type + "_lib_format") ext = getattr (self, lib_type + "_lib_extension") --- 792,799 ---- output_dir=''): if output_dir is None: output_dir = '' ! if lib_type not in ("static","shared","dylib"): ! raise ValueError, "'lib_type' must be \"static\", \"shared\" or \"dylib\"" fmt = getattr (self, lib_type + "_lib_format") ext = getattr (self, lib_type + "_lib_extension") patch Python-2.1.1/setup.py setup.py =================================================================== RCS file: /cvsroot/python/python/dist/src/setup.py,v retrieving revision 1.52 retrieving revision 1.53 diff -c -r1.52 -r1.53 *** python/python/dist/src/setup.py 2001/08/22 19:24:42 1.52 --- python/python/dist/src/setup.py 2001/09/04 09:05:11 1.53 *************** *** 451,457 **** curses_libs = ['ncurses'] exts.append( Extension('_curses', ['_cursesmodule.c'], libraries = curses_libs) ) ! elif (self.compiler.find_library_file(lib_dirs, 'curses')): if (self.compiler.find_library_file(lib_dirs, 'terminfo')): curses_libs = ['curses', 'terminfo'] else: --- 451,458 ---- curses_libs = ['ncurses'] exts.append( Extension('_curses', ['_cursesmodule.c'], libraries = curses_libs) ) ! elif (self.compiler.find_library_file(lib_dirs, 'curses')) and platform != 'darwin1': ! # OSX has an old Berkeley curses, not good enough for the _curses module. if (self.compiler.find_library_file(lib_dirs, 'terminfo')): curses_libs = ['curses', 'terminfo'] else: cd Python-2.1.1/ ./configure --with-dyld --with-suffix=.x change Makefile lines OPT= -g -O3 -Wall -Wstrict-prototypes to OPT= -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp --> Fixes the BSD header problems that have been written up in Apple's internal bug tracking system and LDSHARED= $(CC) $(LDFLAGS) -bundle -undefined suppress BLDSHARED= $(CC) $(LDFLAGS) -bundle -undefined suppress to LDSHARED= $(CC) $(LDFLAGS) -bundle -undefined error -bundle_loader ./python.x BLDSHARED= $(CC) $(LDFLAGS) -bundle -undefined error -bundle_loader ./python.x --> Allows linking in two-level namespace world. Resulting binary will work under 10.0.x until prebinding tool is run at which time it will barf. Not a big deal as anyone who's running 10.0.x should seriously consider upgrading. Core OS says that the use of the -flat-namespace is discouraged and that the use of the bundle_loader is preferred. There is no linkage between the bundle_loader name and the library so we can rename the binary without causing problems.... make Work around small stack size (512k) which causes test_re and test_sre to seg fault limit stacksize 2M make test sudo make install cd /usr/local/bin/ sudo mv python.x python sudo mv python2.1.x python2.1

1 0

Python package maker for OS X Installer.app
by Dinu Gherman Nov. 10, 2001

Nov. 10, 2001

Hi, I'm working on a little Python tool creating OS X packages (extension .pkg), that Installer.app can use to install any- thing, sources or binary files, anywhere. These packages are basically directory wrappers containing an archive created with pax (instead of tar) plus a few additional resources and option files presented and/or used during installation. If anybody is keen on giving it a try, please email me. There are a couple of issues left, like generating multi-volume packages that some more experienced people might be able to help me with, localised installation resources, and the like. Sooner or later, I'd like to include that into distutils, but I'm not sure this will be an easy thing to do... Regards, Dinu -- Dinu C. Gherman ................................................................ "The world becomes a better place as a result of the refusal to bend to authority and doctrine." (Noam Chomsky)

3 2

Re: [wxPython-mac] Re: [Pythonmac-SIG] Re: [wxPython] Compiling wxPython on OS X 10.1
by Jack Jansen Nov. 10, 2001

Nov. 10, 2001

Recently, "Kevin Ollivier" <kevino(a)tulane.edu> said: > -------------------------------------------------- > Nov 9 10:25:54 localhost > /System/Library/CoreServices/Finder.app/Contents/MacOS/Finder: > kCGErrorFailure : _CGSLockAndUpdateWindow: cannot map visRegion shmem > > I haven't yet figured out how to reproduce them (it seems to be behaving at > the moment), but my suspicion (since it's the finder throwing errors) is > that this has something to do with the top menubar and it being 'registered' > as an app. Python does not list its name in the top menubar, even when > running a wxPython script, and also the menubars for the wxPython app do not > appear. (Menubars do appear for compiled wxMac applications.) Interesting. This probably has to do with Python.app not going through the correct initialization sequence. The main program of Python.app is simply the main program for MacPython with everything that didn't work imedeately #ifdeffed out. If someone could look at the code (Mac/Python/macmain.c) and the releant Apple documentation and tell me what to do that would be great. For one, MacPython doesn't initialize the menubar because that is (a) delayed and (b) handled by SIOUX when it's needed. So we probably need some stuff for that, but there may be more missing. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

1 0

Installer builder
by Jack Jansen Nov. 10, 2001

Nov. 10, 2001

Oh yes, one thing that would be really nice for the installer builder for OSX: if you can build the installers so that they can install either into the users home directory or (if the user has the right permissions) into /. Or, in Apple parlance, into the user domain or the local domain. The network domain may or may not be interesting too, I'm not sure, but I think installers behave such that you get that for free. For building installers that install Python extensions there's still a problem, but I don't think we can solve that (so give me hints if you think we can): if an administrator installed Python into the local domain and then a Mere Mortal User wants to install a private extension package Python currently has no good way to deal with this. Python packages are always installed into the Python tree. The workaround would be to install into an almost-empty shadow copy of the Python tree in the users home directory and tell the user to add the relevant directories to their PYTHONPATH. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

1 0

Re: [Pythonmac-SIG] Python package maker for OS X Installer.app
by Jack Jansen Nov. 10, 2001

Nov. 10, 2001

Recently, Dinu Gherman <gherman(a)darwin.in-berlin.de> said: > Sooner or later, I'd like to include that into distutils, but > I'm not sure this will be an easy thing to do... Wow, this would be nice! If you look at Lib/distutils/commands/dist_dumb.py it shouldn't be too hard to model your installer builder so that it should easily plug into distutils... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

1 0

Re: Pythonmac-SIG digest, Vol 1 #893 - 3 msgs
by Gordon Worley Nov. 10, 2001

Nov. 10, 2001

http://www.stepwise.com/Articles/Technical/Packages/InstallerOnX.html On Saturday, November 10, 2001, at 12:20:26 +0100, Just van Rossum wrote: > Dinu Gherman wrote: > >> I'm working on a little Python tool creating OS X packages >> (extension .pkg), that Installer.app can use to install any- >> thing, sources or binary files, anywhere. These packages are >> basically directory wrappers containing an archive created >> with pax (instead of tar) plus a few additional resources and >> option files presented and/or used during installation. >> >> If anybody is keen on giving it a try, please email me. There >> are a couple of issues left, like generating multi-volume >> packages that some more experienced people might be able to >> help me with, localised installation resources, and the like. > > I'd like to learn more about it: right now I know zip about packages. > It would > be really nice to have a .pkg that installs UnixPython 2.1.1 > (especially now > that it doesn't build anymore under 10.1...). Well, don't get to excited. You should probably read this Stepwise article first: http://www.stepwise.com/Articles/Technical/Packages/InstallerOnX.html. Due to some of the reasons mentioned in the article, the Mac GPG project was forced to abandon the .pkg and go with good old fashion tar installers. Not that nice, but it's safe. One thing we have discussed, but not done yet, is use the installer's ability to run a script that is supposed to be for cleanup and use it instead to install via tar like we do now, but so that the user doesn't have to figure out how to use gnutar (we try to keep it simple, but there are always a few ...). The effects of packages are real and have affected mine and other user's systems, too many to safely ignore. I should note all the problems lie in pax and those .bom files, not the rest of the installer. -- Gordon Worley `When I use a word,' Humpty Dumpty http://www.rbisland.cx/ said, `it means just what I choose redbird(a)rbisland.cx it to mean--neither more nor less.' PGP: 0xBBD3B003 --Lewis Carroll

3 2

Re: [wxPython-mac] Re: [Pythonmac-SIG] Re: [wxPython] Compiling wxPython on OS X 10.1
by Jack Jansen Nov. 9, 2001

Nov. 9, 2001

> Sorry for the late response! I built from CVS just fine, but the problem > persists. I think it may be an issue with the wxWindows shared library > though - not Python. I can start up two copies of the Python interactive > terminal just fine. It is only when I try to run a wxPython script in two > terminals that I get the bus error. I haven't done extensive testing, but > this is what I have found so far. Is there any way to track down what "Bus > error" means exactly? =) Then this may be another example of the bug I ran into, but then again it may be something completely different. I'll explain my findings, this may help you along. As of 10.1 Mac OS X is a lot more critical about using Carbon in non-.app programs. Apparently this was already officially illegal in 10.0, but only since 10.1 are there real problems. One thing you cannot do is include window-related portions of Carbon.framework (such as WindowMgr or DialogMgr calls) if no window manager is available (ssh connection as another user than the person logged in on the desktop, OS X Server, >console style login). You will immedeately get kCGErrorIllegalArgument : CGSNewConnection cannot get connection port kCGErrorIllegalArgument : CGSNewConnection cannot get connection port kCGErrorInvalidConnection : CGSGetEventPort: Invalid connection and then a crash. Even if you do have a window manager it seems calling using Carbon from a non-.app program is dangerous. If you call the program once from a terminal window everything seems fine. Except of course that a non-.app program can open windows, but it can't interact with them, show up in the toolbar, etc (you were aware of this, by the way, that you must be a .app style bundle to interact with the user?). But: if you call that same program a second time from a different window you will probably get a coredump. Trying to debug this is difficult (when either copy is run under gdb everything works fine!), but by tracing library loading it seems that the crash is in the initialization of the HIToolbox portion of Carbon. The conclusion of all this is that it seems unsafe to link anything that could be run from the commandline against Carbon. If this appears to be the problem with wxWindows too the solution is simple: use a .app. If you're hosting this in Python already (I think you are, right?) then build the Python.app according to the instructions in Mac/OSX/README in the python disitrbuiton. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

2 1

RE: [Pythonmac-SIG] Re: [wxPython] Compiling wxPython on OS X 10. 1
by Schollnick, Benjamin Nov. 9, 2001

Nov. 9, 2001

It does sound like a wxWindows library issue... This is very similiar to the Tkinter issue, that I raised... (Which is definetly a Tkinter library issue)... Where two copies of the Tkinter library are used at once, it kills the system.... - Benjamin -----Original Message----- From: Kevin Ollivier [mailto:kevino@tulane.edu] Sent: Thursday, November 08, 2001 6:52 PM To: wxpython-users(a)lists.wxwindows.org Cc: wxpython-users(a)lists.wxwindows.org; Wx-Users; pythonmac-sig(a)python.org; wxpython-mac(a)lists.wxwindows.org Subject: Re: [Pythonmac-SIG] Re: [wxPython] Compiling wxPython on OS X 10.1 > This is a nasty Mac OS X 10.1 bug (or a Python bug triggered by 10.1). I fixed > it in the sourceforge CVS repository, so try building from CVS and the problem > should be gone. Sorry for the late response! I built from CVS just fine, but the problem persists. I think it may be an issue with the wxWindows shared library though - not Python. I can start up two copies of the Python interactive terminal just fine. It is only when I try to run a wxPython script in two terminals that I get the bus error. I haven't done extensive testing, but this is what I have found so far. Is there any way to track down what "Bus error" means exactly? =) Thanks, Kevin _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG(a)python.org http://mail.python.org/mailman/listinfo/pythonmac-sig

1 0

Re: [Pythonmac-SIG] Re: [wxPython] Compiling wxPython on OS X 10.1
by Jack Jansen Nov. 8, 2001

Nov. 8, 2001

> Also, I've noticed that with my build of Python (2.1.1 built from python.org > source) there isn't multiple thread support. If I have Python running in one > terminal and try to start it in another, I get a "Bus error." Anyone know a > way around this? This is a nasty Mac OS X 10.1 bug (or a Python bug triggered by 10.1). I fixed it in the sourceforge CVS repository, so try building from CVS and the problem should be gone. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

2 1

(no subject)
by Schollnick, Benjamin Nov. 8, 2001

Nov. 8, 2001

How's in charge of the Documentation? I'd suggest a slight change in FINDERTOOLS.py. The Move function is documented as: "Copy a file to a folder" I'd suggest a change """Copy a File to a folder, src = full filepathname, dst = full path to folder""" I misunderstood and was trying to pass the destination as the full filepathname of the new file. (i.e. src = os v9.1:desktop:shirow:arms1.jpg dst = os v9.1:desktop:shirow:new folder:arms1.jpg ) Simple but frustrating, until I re-read the comment... - Benjamin

1 0