I don't know whether you have access to the plug-in sources or not, but you could certainly test this hypothesis by creating a small object that sits and global scope in order to verify whether it gets constructed. Assuming that it doesn't, you probably have a several choices:
- Create your own "start" stub that calls the static constructors before invoking the start code supplied by the plug-in owner.
- At the time your code is first invoked, call the static construction code.
- Use the startup code intended for drop-ins or shared libraries, which has distinct provision for calling static constructors from the initialize entry point rather than the main entry point.
Codewarrior's static construction routine is called __sinit(). You can see how it's called by looking at the startup code source code provided by Metrowerks (Metrowerks CodeWarrior/MacOS Support/Libraries/Runtime/(Common Sources)/PPC Source/) Note that there are several different varieties of startup code intended for different purposes (plugins, shared libraries, etc...the comments at the top of each tell some of the tale).
James.
On Apr 9, 2004, at 11:05 AM, Adam Heinz wrote:
That's an interesting observation, as my plug-in project does not use __start as its main entry point, instead using a symbol defined by the plug-in owner.
-----Original Message----- From: James Berry [mailto:[EMAIL PROTECTED] Sent: Friday, April 09, 2004 11:34 AM To: [EMAIL PROTECTED] Subject: Re: transcoding crash on mac
On Apr 9, 2004, at 9:17 AM, Adam Heinz wrote:
Oops, I guess I did send this in about a month ago. At least I now know the duration of my long term "memory". :)
What do you mean by "static construction"? I am building Xerces as a statically linked library, but I've used it that way for months before I introduced this bug.
Static construction refers to the runtime-triggered construction of C++ objects that are of global scope. Generally this is invoked by the same startup code that later invokes main(). On CodeWarrior that would generally be the chunk of code called __start, which should be set in your PPC linker panel in the field labeled main:
Since the memory manager passed to transcode at your point of failure is one that is global, my thinking was that your crash could be triggered if this object was not properly constructed (or not yet constructed) at the time of your call, due perhaps to the fact that static construction hadn't occurred.
James.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
