RE: Dynamic loading of System Frameworks???
RE: Dynamic loading of System Frameworks???
- Subject: RE: Dynamic loading of System Frameworks???
- From: "Huyler, Christopher M" <email@hidden>
- Date: Fri, 27 Jun 2003 17:13:40 -0400
- Thread-topic: Dynamic loading of System Frameworks???
I am very aware of all the issues involved with static constructors. What you described happens all over the place and it took me over a week to finally narrow down the problem the first time it occured. However, I am just the person assigned to port this evolution of Windows->Unix->Novell...over to OSX. So changing the engineering of the code is a last resort.
In fact, the first time I tried to run one of our executables I ran into this problem. The work around is the hidden "___initialize_Cplusplus" symbol that is exported by dylib1.o. Adding the flag "-init ___initialize_Cplusplus" to the make script forced all static variables to be bound at load time instead of after the first access. Obviously I can't add a load flag to a precompiled library though.
I changed the library I am loading to "/System/Library/Frameworks/CoreServices.framework/CoreServices" and that brings in CarbonCore by itself. I also did a check for an environment variable in case this library moves in future versions of OSX. Except for little details like obtaining the OS version, we don't need to mess with Apple's frameworks. Our gui is all java and completely independant from this lower level stuff that I'm working on. I think I'm going to stick with this and move on.
Thanks for your input.
-----Original Message-----
From: Alastair J.Houghton [
mailto:email@hidden]
Sent: Friday, June 27, 2003 4:44 PM
To: Huyler, Christopher M
Cc: Macosx-Dev (E-mail); email@hidden
Subject: Re: Dynamic loading of System Frameworks???
On Friday, June 27, 2003, at 07:51 pm, Huyler, Christopher M wrote:
>
Ok, thanks for everyone's help with my Gestalt issues. I finally
>
tracked the problem down to the loader. Although the symbols for all
>
the functions were defined, the libraries in the CoreServices
>
framework had not fully been initialized. This was because I was
>
calling Gestalt inside a constructor.
>
>
Anyway, rather than let the loader decide when to initialize the
>
libraries, I decided to load it myself. (See test program below)
>
However I have one problem. I have to specifiy the full path of the
>
library. Does anyone know if this will be a problem as Apple upgrades
>
their libraries?
It might, especially as CarbonCore.framework is hidden within
CoreServices.framework.
Why do you need to call Gestalt inside a static constructor? Can you
not defer the call until later, for example by allocating the object as
a singleton from your main() function? That would be a *lot* cleaner
than trying to programmatically load the relevant framework so you can
do the call at static construction time.
Static constructors are pretty evil, IMHO, because you cannot be
certain whether frameworks (or libraries) will be initialised properly
when your constructors are executed; after all, *they* may be using
static constructors (or the GCC constructor function extension)
themselves, and the order of construction is undefined, as I am sure
you are aware. They are, of course, fine for simple objects, but I
wouldn't use them for anything more complex than initialising member
variables and maybe calling POSIX/BSD or C/C++ run-time functions
(which should have been set-up by that point).
Kind regards,
Alastair.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.