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

Hi Tim, thanks for the info! A few more questions:

At 1:21 PM -0700 9/20/03, Timothy J. Wood wrote:
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.

If I run strip manually from the command line on the output MachO binary (inside the MacOS folder in the built package), it works as expected. In this case I was using the -x flag, and it stripped all the symbols except the global ones I had explicitly exported via the exports file. nm then shows only these global names, along with any undefined externals (as expected). However, if I add STRIPFLAGS to the PB project, it doesn't seem to do anything, no matter what options I add. I'm sure I'm probably just doing something dumb in PB. Any ideas? Also, with the -s flag, how do I specify the path to a file that is one of the files included in the PB project?

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>

Thanks, that's exactly what I needed! Though, I'm working in a kext so I don't have access to all the C lib stuff used in that file, but it's pretty easily modified. Works great!

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.
References: 
 >Re: PB/GCC exports/statics questions (From: "Timothy J. Wood" <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.