[Python-bugs-list] [ python-Bugs-466907 ] OSX Python cannot run in console (original) (raw)

noreply@sourceforge.net noreply@sourceforge.net
Fri, 26 Oct 2001 05:49:22 -0700

Bugs item #466907, was opened at 2001-10-01 10:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=466907&group_id=5470

Category: Macintosh Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jonathan Wight (schwa) Assigned to: Jack Jansen (jackjansen) Summary: OSX Python cannot run in console

Initial Comment: OS: Mac OS X 10.1 HW: Verified on G4/733 & PowerBook G4/400Version: 'Unix' Python 2.2a4 (also seen on 2.2a3) Configured: --with-suffix=.exe --without-toolbox-glue

Python cannot run on a Mac OS X machine when the user is logged into console mode (using ">console" as login name).

Download .tar.gz, configure python as shown, make, make install. Log out of Mac OS X. Log in as console user: use ">console" as login name. Run python interactively from the shell...

Python will fail to run and emit these errors:

KCGErrorFailure: CGSNewConnection cannot connect to server KCGErrorFailure: CGSNewConnection cannot connect to server KCGErrorInvalidConnection: CGSGetEventPort: Invalid connection

I believe Python is trying to connect to the CoreGraphics server. Why? I don't know (esp. as I've NOT compiled the toolbox glue). Perhaps Python is linking to a Carbon library and the library is automatically trying to open a connection. My makefile skills are not good enough to enable me to check.

Python compiled on OS X without the toolbox glue should essentially be identical to any other 'unix' app compiled for Mac OS X. Doesn't seem to be that way.

Comment By: Jack Jansen (jackjansen) Date: 2001-10-26 05:49

Message: Logged In: YES user_id=45365

Just a quick update so people know I haven't forgotten this bug. It turns out that Apple changed the Carbon.framework initialization: it used to be lazy, initializing carbon portions as needed, but since 10.1 a lot more is initialized up front, and therefore the window server is contacted.

Therefore, as of 10.1, if you are not a windowing program you cannot link against Carbon.framework anymore but must link against some of the subordinate frameworks. This was always true theoretically (it seems), but now it has suddenly become practically true as well.

But: it seems more people are bitten by this, so Apple suggested they may revert on this decision. And on the other hand I'm going to have a look at not linking with Carbon.framework but with CoreServices and/or ApplicationServices in stead.

Comment By: Jonathan Wight (schwa) Date: 2001-10-01 15:17

Message: Logged In: YES user_id=29309

OK... Another Follow Up.

Checked the configure.in file and there is no --without-toolbox-glue switch for configure. There is a --disable-toolbox-glue and --enable-toolbox-glue. The line in the README that states you should use --without-toolbox-glue is incorrect. This is a bug in the documentation! (easy to fix though). I've checked the newly built executable (using --disable-toolbox-glue) with 'otool -l' and the linkage dependencies are gone. This is good.

Unfortunately when the 'make install' stage of the build fails with:

skipping 'gestalt' extension (up-to-date) dyld: ./python.exe Undefined symbols: _Gestalt _PyMac_Error make: *** [sharedmods] Error 67

Comment By: Jonathan Wight (schwa) Date: 2001-10-01 14:33

Message: Logged In: YES user_id=29309

FYI. Running 'otool -l' on the Python executable shows that it is being linked to both:

/System/Library/Frameworks/Carbon.framework

and

/System/Library/Frameworks/Foundation.framework Carbon.framework links in /System/Library/Frameworks/ApplicationServices.framework/ which contains the CoreGraphics framework. I'm assuming that causes CoreGraphics to be initialized (guessing).

Why does a plain 'unix' build of Python link to both Carbon and Foundation?

You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=466907&group_id=5470