Reason of OpenAL uses ccall, even on WinDoze ....
Hello. I am chceking OpenAL CVS Log. Because I'm waiting that my patch is applied. And I saw this message: http://www.haskell.org//pipermail/cvs-libraries/2005-October/004551.html
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
windows.
OpenAL uses ccall on Windows, because OpenAL's aclocal.m4 and configure.ac
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
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/autoconf.ac 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_AL 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 AC_CANONICAL_*, 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 capella.freemail.ne.jp> http://page.freett.com/shelarcy/
On Fri, 21 Oct 2005 03:39:45 +0900, shelarcy
I am chceking OpenAL CVS Log. Because I'm waiting that my patch is applied.
And I saw this message: http://www.haskell.org//pipermail/cvs-libraries/2005-October/004551.html
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 windows.
OpenAL uses ccall on Windows, because OpenAL's aclocal.m4 and configure.ac don't use AC_CANONICAL_*, so $host_os variable has no parameter, then 'ifeq "$(TARGETPLATFORM)" "i386-unknown-mingw32"' doen't work.
configure.ac don't use AC_CANONICAL_TARGET, so $TARGETPLATFORM variable has no parameter - this case. -- shelarcy <shelarcy capella.freemail.ne.jp> http://page.freett.com/shelarcy/
Am Donnerstag, 20. Oktober 2005 20:39 schrieb shelarcy:
I am chceking OpenAL CVS Log. Because I'm waiting that my patch is applied.
It will when I have time to look at it more closely...
And I saw this message: http://www.haskell.org//pipermail/cvs-libraries/2005-October/004551.html
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 windows. [...]
I am not sure if we are talking about the same problem here: As I've recently noticed to my surprise, the API entries in openal32.dll use the _cdecl calling convention! AFAIK this is very unusual for a WinDoze DLL, so the above commit makes sure that the Haskell binding always uses ccall, even on WinDoze. I've raised this issue on the OpenAL developer's list and asked for the rationale behind this, but got no real answer: http://opensource.creative.com/pipermail/openal-devel/2005-October/001555.ht... My personal guess is that this just happened by accident. :-) Cheers, S.
On Sat, 2005-10-22 at 16:40 +0200, Sven Panne wrote:
I am not sure if we are talking about the same problem here: As I've recently noticed to my surprise, the API entries in openal32.dll use the _cdecl calling convention! AFAIK this is very unusual for a WinDoze DLL, so the above commit makes sure that the Haskell binding always uses ccall, even on WinDoze.
I've raised this issue on the OpenAL developer's list and asked for the rationale behind this, but got no real answer:
http://opensource.creative.com/pipermail/openal-devel/2005-October/001555.ht...
My personal guess is that this just happened by accident. :-)
I thought it was rather the other way around. I was under the impression that most Win32 DLLs use the ccall calling convention and that it was only the windows system dlls that use the stdcall convention. I know that the Gtk+ dlls use ccall on win32. Furthermore they can be used from programs compiled with MSVC; that is they follow the MSVC ABI (including the MSVC bitfield packing convention). Duncan
Am Samstag, 22. Oktober 2005 17:24 schrieb Duncan Coutts:
I thought it was rather the other way around. I was under the impression that most Win32 DLLs use the ccall calling convention and that it was only the windows system dlls that use the stdcall convention. [...]
Hmmm, I thought that at least Microsoft itself more or less equated "DLL" and "stdcall", e.g. Visual Basic can only handle "stdcall" DLLs, at least up to and including version 6.0: http://support.microsoft.com/default.aspx?scid=kb;en-us;153586 I don't know if that has changed. Happily enough, I don't have to use VB... :-) Cheers, S.
Duncan Coutts wrote:
I know that the Gtk+ dlls use ccall on win32. Furthermore they can be used from programs compiled with MSVC; that is they follow the MSVC ABI (including the MSVC bitfield packing convention).
GTK+ has to use ccall, as it's common practice to pass excess
arguments to functions, which won't work with stdcall.
--
Glynn Clements
On Sat, 22 Oct 2005 23:40:33 +0900, Sven Panne
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 windows. [...]
I am not sure if we are talking about the same problem here: As I've recently noticed to my surprise, the API entries in openal32.dll use the _cdecl calling convention! AFAIK this is very unusual for a WinDoze DLL, so the above commit makes sure that the Haskell binding always uses ccall, even on WinDoze.
Okay, I see.
I am chceking OpenAL CVS Log. Because I'm waiting that my patch is applied.
It will when I have time to look at it more closely...
I'm looking forward to it. -- shelarcy <shelarcy capella.freemail.ne.jp> http://page.freett.com/shelarcy/
participants (4)
-
Duncan Coutts -
Glynn Clements -
shelarcy -
Sven Panne