Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

PB/GCC exports/statics questions

Hi -

I'm a PB newbie, and a CW veteran. I'm converting a CW project to PB, and I'm having trouble figuring out the PB eqivalents to some of the things I was doing in the CW project, so I thought maybe someone on this list might have some ideas. Hopefully these aren't too obvious (I did try to find some answers in the archives first! :-)

The project in question is a shared library. Here are my questions:

1) I'm having trouble controlling exports. I have added an exports file, with the names of the only routines that I want exported. Now "nm" reports only those routines in the exports file as external (plus some undefined externals referencing routines defined elsewhere, which is fine). However, I'm wondering if there's a way to make ALL other functions that I'm not exporting to not be visible at all, or at least the names (for my release build). In the CW version, for the release build I could do this by turning off "trackback tables". Is there a similar setting in PB that I'm missing? The goal would be that in the relase build, "nm" would only report the actual names of functions that I specifically export, plus any undefined externals. All others would have some unknown name. Is this possible? BTW the CW version was CFM, the PB version is Mach-O. Is this some limitation of the Mach-O format?

2) In the CW version, I had custom CFM initialization/termination routines. These were in fact necessary for calling the MSL __initialize/__terminate C/C++ runtime support functions (for apps, this would happen automatically). An additional side effect is this let you control exactly when static initialization/destruction took place. In PB, I see how to have Mach-O MODULE_START/MODULE_STOP functions, but I don't see any way to call the corresponding C/C++ runtime start/stop functions, or even if these functions exist. If I use "nm" on my library, I see external undefined references to _OSRuntimeIntializeCPP and _OSRuntimeFinalizeCPP, which look like what I need, and it does appear that these functions must be getting called as statics (at global scope) are in fact having their ctor/dtor called. I'm just wondering if there's any way to have manual control over this.

3) Related to the last question, in a search of this archive I found reports that there's a GCC bug where in dynamically loaded modules, static objects that are within a function or block scope do not have their destructors called correctly. It appears that instead these go to a call to _atexit, which is supposed to be for applications (not shared libs). I'm wondering if this has been fixed in the GCC 3.3 update? If not, is there any workaround short of ensuring that all static objects are not within a function or block scope (a real pain to change in my current codebase)? Could I hack something like defining my own _atexit() function within my shared lib, which then calls _OSRuntimeFinalizeCPP(), or something ugly like that??

Thanks,
Jim
_______________________________________________
projectbuilder-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/projectbuilder-users
Do not post admin requests to the list. They will be ignored.


Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.