RFC: dsound: Add support for enumerating capture devices through openal, try 4

[Maarten Lankhorst]

Hi Ken,

Ken Thomases schreef:
> On Dec 2, 2009, at 12:11 PM, Maarten Lankhorst wrote:
>
>> This patch doesn't apply, just a rfc email to see if this approach is 
>> correct :)
>
>> +static void *openal_handle = RTLD_DEFAULT;
>
>> +#ifdef SONAME_LIBOPENAL
>> +    char error[128];
>> +    openal_handle = wine_dlopen(SONAME_LIBOPENAL, RTLD_NOW, error, 
>> sizeof(error));
>> +    if (!openal_handle)
>> +        ERR("Couldn't load " SONAME_LIBOPENAL ": %s\n", error);
>> +#endif
>> +#define LOAD_FUNCPTR(f) \
>> +    if((p##f = wine_dlsym(openal_handle, #f, NULL, 0)) == NULL) { \
>> +        ERR("Couldn't lookup %s in libopenal\n", #f); \
>> +        failed = 1; \
>> +    }
>> +
>> +    LOAD_FUNCPTR(alcCreateContext);
>
> By defaulting to RTLD_DEFAULT on the Mac (where SONAME_LIBOPENAL won't 
> be defined), is there any risk that wine_dlsym will find the symbols 
> from Wine's openal32.dll.so rather than the linked OpenAL framework?  
> If it does, is that a problem?
>
> I had proposed using RTLD_NEXT for the default to avoid that 
> possibility, although it seems that RTLD_NEXT isn't universally 
> available.  We might use RTLD_NEXT if it's defined and RTLD_DEFAULT 
> otherwise.
Those symbols are prefixed with wine_ and libopenal is static linked to 
openal32, so there cannot be duplicate names between the 2. We don't 
have to worry about the win32 symbol names, since they're not handled by 
wine_dlsym. Just to be sure I tested, and confirmed that.

Cheers,
Maarten.