I see. Yes, the first call your app makes to the HAL will load the plug-in. It wasn't clear from your earlier postings that this was the case.
At any rate, I'm not sure I understand what you are doing, so correct me please:
1) You have an application that wants to use some kind of back channel communication to talk to your HAL plug-in. 2) The back channel is statically initialized global variables in the the plug-in's dyld.
My question is how does the app get access to the plug-in's globals? Is it linking against the plug-in, which exports the appropriate symbols? It sounds like it to me, because I think that the problem you seeing is aliasing. Your app is getting your plug-in loaded twice. Once by the loader when the process boots up and again by the HAL when it loads the bundle. Consequently, your app is seeing dead globals that aren't actually getting initialized, whereas your plug-in is working fine with the correct set of globals.
The right way to communicate with a dynamically loaded bundle is via CFBundle calls, CFPlugIn calls, or low-level dyld calls. However you do it, the app has to get ahold of the thing that the HAL loads, and then dynamically load the symbols it needs (or interface if it uses CFPlugIn). On Feb 1, 2005, at 2:47 AM, Stéphane Letz wrote: ------------------------------ Message: 8 Date: Mon, 31 Jan 2005 12:29:10 -0800 From: Jeff Moore <email@hidden> Subject: Re: Initializing static C++ class variable in a HAL plugin problem (Modifi? par St?phane Letz) To: CoreAudio API <email@hidden> Message-ID: <email@hidden> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed C++ statics are loaded as the dyld that contains them is loaded and prepped for usage. What is probably happening is that your ObjC code is executing before the HAL has had a chance to load your plug-in. Consequently, none of those static variables have been initialized yet. On Jan 31, 2005, at 5:26 AM, Stéphane Letz wrote: The load code is the following: + (void) load { _MTCoreAudioHardwareDelegate = nil; AudioHardwareAddPropertyListener ( kAudioPropertyWildcardPropertyID, _MTCoreAudioHardwarePropertyListener, NULL ); } From the MTCoreAudio framework project : http://aldebaran.armory.com/~zenomt/macosx/MTCoreAudio/ i n file MTCoreAudioDevice.m The strange thing is that , the AudioHardwareAddPropertyListener call cause the HAL to load my plug-in (I know that because the plug-in Initialize method is correctly called), but the C++ static variables are *not* initialized. Thus its is still not clear is the problem is in the dyld loader or somewhere else. Stephane Letz I'm using an Objective C framework that implement some initializing code in its "load" method. This initializing code access a AudioHardarePlugIn loaded by the HAL. This plug-in use static C++ class variables. It appears that the static C++ class variables are not initialized properly. I read in the following page that says "load " is executed before main : http://www.redhat.com/docs/manuals/enterprise/RHEL-3-Manual/gcc/ objective-c.html Since "load" is called early, it seems that static C++ class variables are not yet initialized. I'm a bit confused : does the HAL plug-ins require some special linker option to be used to be sure C++ class variables will be initialized? Of is the problem in the fact that Objective C load method should not be used this way? -- Jeff Moore Core Audio Apple
--
Jeff Moore
Core Audio
Apple
|