[Pythonmac-SIG] Problem with compiling frozen module as bundle, bundle_loader option, and CodeWarrior

[Read Roberts]

Thank you for your response! This was very useful, and gets me past 
my blocking problem.  Since I am compiling with two-level name-space, 
I can easily, without conflicting with the host application's 
definition of 'environ',  declare a global variable 'environ' in my C 
wrapper for the frozen Python bundle, and initialize it to a real 
value on entry with the NSGetEnviron().

Even more usefully, this sent me back to the posix module, where I 
now notice that if I had compiled with the preprocessor def 
WITH_NEXT_FRAMEWORK, then posix.c would have declared a static 
variable 'environ' and initialized it with  NSGetEnviron ().   I 
built  the Python for use with my freeze module  with the 
'--enable-framework' option off, since I wanted bundles rather than 
dylibs. As a result, WITH_NEXT_FRAMEWORK does not get set. Could 
there be another macro definition for special-casing access to teh 
environ symbol that would depend only on the host environment being 
MACH-0, and not on building a framework based Python?  Also, I am not 
clear if I can get the static Python library that I need if I turn 
the  '--enable-framework' option on; I will try this as well.

I am forced to build a bundle file since I need a loadable library 
that can be loaded/unloaded by several different applications, and 
will be distributed as a separate plug-in from any of the 
applications, and I do not have access to the build environments of 
the target applications.

Thank you again for your help.

I am still curious if anyone knows whether CodeWarrior supports an 
equivalent of the gcc '-bundle_loader' option, although I no longer 
immediately need this information.




At 20:01 -0500 3/29/04, Bob Ippolito wrote:
>On Mar 29, 2004, at 7:06 PM, Read Roberts wrote:
>
>>  I have a 'frozen' python script that compiles nicely as a Mach-0 
>>bundle library  with gcc, and is looadable as such by any random 
>>Mac program. However, I have run into a glitch with converting to 
>>CodeWarrior.
>>
>>  The Python script uses the 'os' module. This in turn loads the 
>>'posix' module, and one of the setup functions in 'posix' 
>>references the symbol 'environ'. 'environ' is defined only in the 
>>crt.0 library that is linked only  into applications. As a result, 
>>in order to compile my bundle library, I have to use the 'gcc' 
>>option ' -bundle-loader <some application>' so that the gcc linker 
>>will find a source for the symbol 'environ'.
>>
>>   Now, I need to do the same thing in CodeWarrior, but I have not 
>>been able to find any way to set this option. Can any one tell me 
>>how to do this in CodeWarrior 9.1?
>>
>>   I did find an alarming e-mail as of 5.13.2003 which commented 
>>that CW 8.x is missing this feature, but haven't been able to 
>>confirm it, or confirm with respect to CW 9.1
>>
>>  P.S. My bundles that link with Python also are missing the symbol 
>>'_file'. Can anyone tell me where that comes from? My project 
>>contains  the frameworks Python , Carbon, and System, and the 
>>bundle1.o object file.
>
>What's wrong with the application bundle approach?  It's much easier 
>to deal with...
>
>I don't know anything at all about CW, but the way you are supposed 
>to find symbols like _environ from a shared library or bundle is to 
>use the accessor functions (see /usr/include/crt_externs.h).  It's 
>entirely likely that the "freeze" functionality just doesn't 
>understand the Mach-O way to do it, because all of the development 
>effort has been on the application bundle approach.
>
>-bob

-- 
-----------------------------------------------------------------------------------------
Read K. Roberts			rroberts at adobe.com
Adobe Systems San Jose TW12 	(408)-536-4402 on Weds
San Francisco 			(415) 642-5642 Mon, Tues, Thurs, Fri