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

Re: PB/GCC exports/statics questions

On Friday, September 19, 2003, at 01:06 AM, Jim Wintermyre wrote:
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?

There are more details in 'man strip', but you can set STRIPFLAGS to '-s FileName' where the file contains the names of symbols to keep.


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.

You shouldn't have to do anything to get libstdc++ initialized. Maybe I'm misunderstanding the question, though.

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

This is certainly an annoying bug, but it isn't too hard to workaround. What we did was to realize that we could link in a 'atexit' implementation to our bundle that would get linked to instead of the one from the system library.

You should be able to just add this file to your bundle/shared library project and hopefully it will start working better.

<http://www.omnigroup.com/~bungi/OGPBundleAtUnload.cpp>

-tim
_______________________________________________
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.
References: 
 >PB/GCC exports/statics questions (From: Jim Wintermyre <email@hidden>)



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.