Re: [Pyobjc-dev] Python rather than ObjC for main?

[<bb...@ma...>]

On Friday, November 8, 2002, at 12:04 PM, Peter Montagner wrote:
> On Saturday, November 9, 2002, at 01:47 AM, bb...@ma... wrote:
>
>> On Friday, November 8, 2002, at 08:21 AM, Peter Montagner wrote:
>> ... excellent sleuth work deleted -- thank you for tracking this=20
>> down!!! ...
>
> Well, it didn't really get us anywhere. Just to elaborate, my test=20
> copy of PythonEdit with the python start code works if you setenv=20
> CFProcessPath to the right place before you run it. I really wish CF=20=

> would not decide where the executable is so quickly. Why does it not=20=

> check the first time you actually ask for it (with CFBundle et al)? It=20=

> would be great if we could sneak a setenv() call somewhere in PyObjC=20=

> but by then CF has already looked and decided that /usr/bin/python is=20=

> the path to the executable. Arrgh.

Anything that fills in gaps in my knowledge is generally a good thing=20
-- so, again, thanks for doing a bunch of legwork.

The setenv() call would have to happen in the main [python] executable.=20=

  The PyObjC module is too late because it is dynamically loaded.   =20
Back to square one-- we could use a Python script in the app wrapper,=20
but it would (a) be slower and (b) not add any functionality over the=20
current bootstrap executable.

BTW:  There is nothing app specific about the bootstrap executable. =20
You don't even need to compile it to use it in another project-- just=20
add a copy files phase that copies the executable into the Executables=20=

area of the app wrapper and make sure that the executable name=20
attribute in the info dictionary of the app wrapper is set correctly.

> I think I know what will help me: a proper build of python. So what is=20=

> recommended? CVS python? Stable python? Fink?

Fink rocks.

I would go with Fink -- make sure you follow the 10.2 instructions at=20
fink.sourceforge.net.   It keeps itself up to date quite nicely and is=20=

incredibly easy to uninstall (fink remove python -- once it is built,=20
there will be a debian package containing the python build and,=20
therefore, a subsequent fink remove / fink install of python does not=20
require it to be rebuilt).   Go with 'python-nox' if you don't have or=20=

want X11 installed.

The Fink build of python, like the Apple build, does not include an ssl=20=

enabled socket module.  Trivial to fix;  go to versiontracker and=20
search for 'python' in the OS X area and grab the package I put=20
together.

The framework build [and, I would guess, MacPython] also work, from=20
what I hear.  I personally don't use them because making sure my code=20
works out of the box on OS X 10.2 and making sure my code that should=20
be portable to other Unix like systems is portable are the two top=20
priorities for me...

>>> Anyway, a function called __CFInitialize() is called by _start() (or=20=

>>> something else before main() is called, I'm not sure. Couldn't find=20=

>>> the source for _start()). Down the bottom of the function is this >=20=

>>> line:
>>
>> _start() is defined in crt1.o -- see /usr/lib/crt1.o -- and is a part=20=

>> of the C runtime [crt] bootstrap that is built as a part of gcc.    =20=

>> It calls a series of module init functions-- modules in the most=20
>> primitive sense [mach-o files involved in the linking, I believe]--=20=

>> and is what triggers, say, the static initialization mechanism in=20
>> C++.   Immediately after initialization the modules, it initializes=20=

>> the ObjC runtime, if present.
>
> Unfortunately, I can't read binary :-)

A trick:

     otool -TtVv /usr/lib/crt1.o

This dissassembles the executable code within a mach-o file (the TEXT=20
segments).  I'm not much of an assembly person, myself, but was able to=20=

figure out the above from that output and from my knowledge of how C++=20=

and ObjC initialize as an app loads.

> Even a disassembly of it is pretty painful because none of the=20
> interesting stuff is in the module. _start() calls a couple of dyld=20
> functions (I think) then jumps to a couple of functions that have=20
> presumably just been loaded. It has to be something like that because=20=

> the jumps are to addresses past the end of the TEXT segment. They are=20=

> also all nicely prebound so that all I see is a hexadecimal address,=20=

> no stubs. I couldn't find the crt.c file and frankly it's not really=20=

> worth my time anymore.

The module init likely walks the list of Mach-O modules that have been=20=

loaded into the app [each dylib will define a single module -- maybe=20
more than one, I can't remember] by calling a specifically named=20
function, it would appear.

>>> =A0_CFProcessPath(); =A0 =A0 =A0 =A0// cache this early
>>>
>>> This means that CF already has the process path determined and=20
>>> cached before main() is even called. Damn. I was getting hopeful for=20=

>>> a while there.  Well, I think I give up.
>>
>> No reason not to outside of curiosity.   We can't control the order=20=

>> of static initialization and, therefore, could not guarantee that a=20=

>> piece of our code-- module initialization code-- would be executed=20
>> prior to the call into the Core Foundation initialization.
>
> I'm a very curious person. But one can only be so curious when one is=20=

> trying to read messy, #ifdef laced source code through a CVSWeb site=20=

> over a dialup link.

Agreed.  C in this form is very much like macro assembly....

>> In any case, all of this-- the whole execve() style bootstrapper-- is=20=

>> just a hack that'll go away as soon as we have an embeddable build of=20=

>> Python shipping with OS X.
>
> Yeah, I know. I just had the kluge alert going off in my head and I=20
> felt compelled to try and fix it. Anything other than the current hack=20=

> is going to be an even bigger hack. You guys have done a great job.

Thanks.  It just got better.  If you cvs update the pyobjc source tree,=20=

the new Cocoa-Python project template has been cleaned up a bit.   BTW:=20=

  You can create a symlink from /Developer/ProjectBuilder Extras/Project=20=

Templates/... wherever ... to the project template(s) in the pyobjc=20
source tree directly.   Just make sure you don't end up w/a .pbxuser=20
file in the template pbproj....

b.bum