On Sunday 25 March 2007 04:38, Nobuhito Mori wrote: > [...] Though there are clearly "link errors", I can not understand why it > happens. By option "-package ALUT", libalut.a (which made by pexports and > dlltool because I do not know original "alut.lib" can be used by mingw) and > other necessary libraries are automatically linked, I think. What is "@8" > of "[EMAIL PROTECTED]"? [...]
Just a little bit of background: Because Microsoft has decided that *nothing* will be easy or straightforward on their platform, they introduced tons of different calling conventions: http://msdn2.microsoft.com/en-us/library/984x0h58.aspx When a function is called, arguments are pushed onto the stack. The question is: Who cleans up the stack then, the caller or the callee? For functions with variable argument lists like printf in C the usual answer is: The caller, because it is the only one who knows what was pushed (__cdecl convetion in MS speak). OTOH, having the cleanup code in the callee leads to slightly smaller code, assuming that a function is called more than once (__stdcall in MS speak). To catch a mismatch in calling conventions at link time (and because of a few other reasons), functions expection to be called the __stdcall way get a "@BytesOnTheStackToBeCleanedUp" suffix. Historically, DLLs on Windows use the __stdcall convention, but there is no deep reason why. The OpenAL DLL uses __cdecl, but the reasons for this have probably vanished alongside Loki Software itself, the initial designers of OpenAL. ALUT is used with OpenAL, so it made sense to me to choose the same calling convention as the OpenAL DLL, i.e. __cdecl, for the ALUT DLL. Looking at the OpenAL and ALUT Haskell packages, I think that there are some cut-and-paste bugs from the OpenGL/GLUT packages (where the DLLs use __stdcall). I'll have a look at it, but in the meantime could you please add a detailed description to the corresponding ticket of how you installed the OpenAL/ALUT packages and which OpenAL/ALUT DLLs/libs you used, how you tried to convert them etc. (command lines, outputs, ...)? I'd just like to make sure that I'll reproduce exactly what you did. Cheers, S. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe