[ shouldn't this be on the curl-library@ list? ]

Gisle Vanem wrote:

> As it is now all applications using libcurl (either dynamically or
> the static lib) must be built with the same calling convention as
> libcurl was built with. Normally this would be 'cdecl' (which is
> implicit and the only (?) possible calling-convention in gcc).
>
> Sometimes mixing e.g. 'fastcall', 'stdcall' and 'cdecl' would be
> useful. I guess this would be an issue only on Windows and DOS
> using non-gcc compilers.

I don't know why you exclude gcc here, as it fully supports all of those
calling conventions on Windows (i.e. Cygwin and MinGW.) In fact the
entire Win32 API uses the stdcall calling convention (aka WINAPI in the
headers) which means it's a requirement that a compiler support this in
order to do anything non-trivial on Win32.

> Should we proceed with this idea? Any comments on the pros and cons.

Frankly it sounds like a horrible idea. Library versioning is already
tricky enough that I don't see why you'd want to intentionally muddy the
waters further by making it easier to produce a DLL that's incompatible
-- especially on a platform where users are accustomed to using someone
else's build rather than building from source. There's already enough
problems with people that can't figure out how to choose the right
MT/ST/static/dynamic version of the MSVCRT that adding yet another
variable to the ABI matrix just seems like asking for trouble.

Brian
Received on 2007-11-01