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

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

On Friday, November 8, 2002, at 08:21 AM, Peter Montagner wrote:
... excellent sleuth work deleted -- thank you for tracking this=20
down!!! ...

> 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 > =
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.     It=20=

calls a series of module init functions-- modules in the most primitive=20=

sense [mach-o files involved in the linking, I believe]-- and is what=20
triggers, say, the static initialization mechanism in C++.  =20
Immediately after initialization the modules, it initializes the ObjC=20
runtime, if present.

> =A0_CFProcessPath(); =A0 =A0 =A0 =A0// cache this early
>
> This means that CF already has the process path determined and cached=20=

> before main() is even called. Damn. I was getting hopeful for a while=20=

> there.  Well, I think I give up.

No reason not to outside of curiosity.   We can't control the order of=20=

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

of our code-- module initialization code-- would be executed prior to=20
the call into the Core Foundation initialization.

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.

b.bum