Reason of OpenAL uses ccall, even on WinDoze ....

shelarcy shelarcy at
Thu Oct 20 14:38:45 EDT 2005


I am chceking OpenAL CVS Log. Because I'm waiting that my patch is applied.

And I saw this message:
> Log:
> For some obscure/unknown reason, OpenAL uses ccall, even on WinDoze...

So I send again below message, and I notice where is the problem on  

OpenAL uses ccall on Windows, because OpenAL's aclocal.m4 and
don't use AC_CANONICAL_*, so $host_os variable has no parameter, then
'ifeq "$(TARGETPLATFORM)" "i386-unknown-mingw32"' doen't work.

I noticed this problem 2. of below message.

On Mon, 26 Sep 2005 22:41:11 +0900, shelarcy <shelarcy at> wrote:
> I tried to build CVS HEAD, build is success on Windows.
> But build is failure on Mac OS X, because you missunderstood my patch's
> Mac OS X support part.
> OpenAL/ must change two point.
> 1. AC_SEARCH_LIBS doesn't find framework's Library, Mac OS X can use
>    "-framework OpenAL" flag instead of "-l openal" option, and  
>    FP_HEADER_ALC can find headers. So you must change to declare
>    AC_SUBST([AL_FRAMEWORKS]) before checking to find library instead
>    of before checking to find header.
> 2. OpenAL doesn't inherit platform parameter and dosen't declare  
>     so $host_os variable has no parameter and "case $host_os in" doesn't  
> work.
>    (I forgot this point earlier patch.)
> I send patch to fix these points. This patch tested on both Windows and  
> Mac OS X
> platform.
>> If things go wrong, I need a log of the configuration and
>> building + the generated config.log in fptools/libraries/OpenAL.
> And I send Mac OS X's config.log by CVS HEAD.

shelarcy <shelarcy>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openal-mac.patch
Type: application/octet-stream
Size: 912 bytes
Desc: not available
Url :

More information about the Libraries mailing list