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:
40soundspectrum.com
This email sent to email@hidden