Re: Xcode 2.3 breaks bundle static object destruction? fuse-cxa-atexit? Help!
Re: Xcode 2.3 breaks bundle static object destruction? fuse-cxa-atexit? Help!
- Subject: Re: Xcode 2.3 breaks bundle static object destruction? fuse-cxa-atexit? Help!
- From: "Andy O'Meara" <email@hidden>
- Date: Mon, 12 Jun 2006 18:40:03 -0400
- Thread-topic: Xcode 2.3 breaks bundle static object destruction? fuse-cxa-atexit? Help!
My best and only guess (without knowing wxWidgets) is that it perhaps does
initialization in a constructor of a static object:
// snip
// foo.cpp
class AppInitter {
AppInitter() {
// Do important init stuff here
}
};
AppInitter sAppInitterInstance;
// snip
Because sAppInitterInstance is never referenced, if the linker is set to
strip unreferenced static objects, the important init stuff will never get
called. Try turning off all dead code stripping and see if the crash goes
away.
We feel your pain!
andy
On 6/12/06 5:52 PM, "William H. Schultz" <email@hidden> wrote:
> Okay, I got a similar crash when I upgraded to 10.3, but my issue was
> when the bundle loads, so the atexit stuff didn't help any. I've
> since reverted to Xcode 2.2.1, since we are close enough to a final
> release that I probably shouldn't have updated anyway.
>
> I didn't explicitly use any module initialization or deinitialization
> functions. However, there were several static wxWidgets items that
> were interdependent, and this is where the crash occurred. I don't
> have the time right now to dive any further into what was going on,
> but I was thrilled when I saw that other people were having similar
> issues, so I figured I would at least mention mine.
>
>
> Thanks,
>
> Hank Schultz
> http://www.cedrus.com/
>
>
> On Jun 11, 2006, at 8:37 AM, Allen Cronce wrote:
>
>> Hi Jim,
>>
>> Fire up the way back machine ;-)
>>
>> Once upon a time there were the CALL_ON_LOAD/CALL_ON_UNLOAD pragmas.
>> These worked under CW for Mach-O executables.
>>
>> I think in recent times these pragmas worked under Xcode/gcc. But
>> apparently there was a period where they where unimplemented, so there
>> was an ugly work around using the SECTION pragma to force a function
>> reference into either the __mod_init_func or __mod_term_func
>> section of
>> the _DATA segment.
>>
>> And in any case, the CALL_ON_[UN]LOAD pragmas are deprecated with
>> gcc 4.0:
>>
>> http://developer.apple.com/qa/qa2005/qa1429.html
>>
>> So the short answer is you're right. The only reasonable way to
>> specify
>> module init/term procs with today's tools is via
>> __attribute__((constructor)) and __attribute__((destructor)).
>>
>> Best,
>> --
>> Allen Cronce
>>
>> Jim Wintermyre wrote:
>>> Allen Cronce wrote:
>>>
>>>> I would have thought that relying on atexit for cleanup of a
>>>> non-application executable could result in undefined behavior.
>>>> Because
>>>> you really don't have control over when your bundle is unloaded.
>>>>
>>>> Shouldn't you use a module termination proc or "__attribute__
>>>> ((destructor))" instead?
>>>
>>> I've never found a way to to have a "module termination proc" for a
>>> Mach-O bundle (we had them in the CFM days), so I thought
>>> "__attribute__((destructor))" was the only way to go. Am I missing
>>> something?
>>>
>>> Thanks,
>>> Jim
>>>
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Xcode-users mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>> 40cedrus.com
>>
>> This email sent to email@hidden
>>
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden