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

[Peter M. <zig...@po...>]

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 copy=20=

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.

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

recommended? CVS python? Stable python? Fink?


>> 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 C++.=20=

>   Immediately after initialization the modules, it initializes the=20
> ObjC runtime, if present.

Unfortunately, I can't read binary :-)

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, no=20=

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

my time anymore.


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

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.


> 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.

Peter=