Re: Initializing static C++ class variable in a HAL plugin

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