Charles Davis writes:
> You can. The "proper" way to do this is to use the CFBundle API. First
> you need to find the framework. Typically, it's in
> /System/Library/Frameworks, but the user might have a custom OpenAL in
> /Library/Frameworks or in $HOME/Library/Frameworks. Then we tack on the
>
Alexandre Julliard wrote:
> Maarten Lankhorst writes:
>
>> Hello Alexandre,
>>
>> Alexandre Julliard schreef:
>>> Openal missing at compile time or at runtime should be handled the same
>>> way, i.e. by reporting no sound devices. It doesn't make sense to have
>>> two different failure modes.
>>>
Maarten Lankhorst writes:
> Hello Alexandre,
>
> Alexandre Julliard schreef:
>> Openal missing at compile time or at runtime should be handled the same
>> way, i.e. by reporting no sound devices. It doesn't make sense to have
>> two different failure modes.
>>
> Mac OSX can only link directly
Hello Alexandre,
Alexandre Julliard schreef:
Maarten Lankhorst writes:
Without openal at compile-time, dsound will still build, but report no
sound devices found. Some games or other applications may refuse to
run if no dsound devices are found, so its recommended that you build
with opena
Maarten Lankhorst writes:
> Without openal at compile-time, dsound will still build, but report no
> sound devices found. Some games or other applications may refuse to
> run if no dsound devices are found, so its recommended that you build
> with openal. If openal is compiled in, but missing at
Hi all,
This message is mostly aimed towards package maintainers, since one of
the discussions at wineconf last year was that package maintainers would
like to hear in advance about changing dependencies.
Wine's DirectSound implementation will, in the next release or the
release after that,
