Re: Avoiding destructors while still calling atexit handlers
Re: Avoiding destructors while still calling atexit handlers
- Subject: Re: Avoiding destructors while still calling atexit handlers
- From: James Milne <email@hidden>
- Date: Sun, 8 Jan 2006 20:17:03 +0000
On 8 Jan 2006, at 19:37, Brad Oliver wrote:
On Jan 7, 2006, at 8:31 AM, email@hidden wrote:
I would like to comment that I think Steve's suggestion is a much
more *maintainable* solution.
In our case, that would be the least maintainable solution. We're
porting games from Win32 to Mac, so the original code is not ours
to maintain.
The first problem is that this would result in (a guess) slightly
under 1000 code changes in one of our current projects. The second,
and bigger, problem is that each time we merge in PC patch code (or
migrate to an expansion pack code base), we then have to go through
and double-check any new destructors in the PC code as well as our
prior Mac-only patches. The cycle then repeats when we hit a new
game with a dtor-ordering problem.
If there's no easy way to skip the dtor phase then so be it - we'll
have to live with it. The CodeWarrior runtime had a simple function
you could override that would skip this and only this step. I was
hoping the runtime gcc uses had something just as straightforward.
I'm presently working to solve a similar problem. I'm porting our
game engine to Mac OS X. It already supports a variety of platforms,
and whilst all the code is ours to control, I don't want to have to
force changes on whole game source trees just to support our Mac
SKUs. I get enough stick for working on the Mac as it is :-)
I'm wanting to have some code run before all the C++ global
constructors in an application are executed. I need to set up our
memory & file system managers so that any other subsystems which
require them can be initialised.
I'm presently looking at adjusting crt1.o. The code to the C startup
operations is in Csu-57 in Darwin, so I can theoretically adjust it.
I've compiled my own version of crt1.o and I include it in my final
app by dragging it into the project, and passing '-nostartfiles' in
the linker flags. Sadly, when I run the applications linked against
it, they crash.
If I could figure out how to successfully rebuild crt1.o such that my
apps don't crash when they use my version of it, I'd be off and
running; I would have full control over when code runs relative to
the global static object constructors & destructors.
I'd suggest this as a similar avenue of research. I'll let you know
when I manage to rebuild crt1.s successfully.
--
Kind regards,
James Milne
_______________________________________________
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