We never actually "chose" to use cdecl; it was simply the default used by
MSVC. This whole idea that the programmer should have to choose between
calling conventions is a bit strange and inconvenient. The
LIBPROTOBUF_EXPORT annotations are annoying enough; I hope we don't have to
litter our code with calling convention annotations as well. Is there any
way we can modify the existing LIBPROTOBUF_EXPORT macro to specify calling
Your work-around of compiling the DLL with different settings should work
fine. I can't imagine any reason why stdcall would cause problems. Out of
curiosity, what is the binary size difference between the cdecl version and
the stdcall version? The MSDN docs claim stdcall produces smaller binaries.
On Tue, Mar 15, 2011 at 5:05 AM, Kostya Y <kosty...@gmail.com> wrote:
> It seems like the calling convention used in libprotobuf's vc project
> is cdecl while the Microsoft's preferred way (or the default one) is
> Is there a reason why cdecl was chosen?
> I am getting linker errors as the functions are not strictly defined
> as cdelc so the linker assumes that it should use default project
> settings which in my case is stdcall. As a result I get the following
> error LNK2001: unresolved external symbol "void __stdcall
> google::protobuf::internal::VerifyVersion(int,int,char const *)" (?
> As you can see it expects it to be __stdcall (projects settings are
> set to default naming convention stdcall) while it is exported as
> Any suggestions how to work around it?
> - Kostya
> You received this message because you are subscribed to the Google Groups
> "Protocol Buffers" group.
> To post to this group, send email to firstname.lastname@example.org.
> To unsubscribe from this group, send email to
> For more options, visit this group at
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To post to this group, send email to email@example.com.
To unsubscribe from this group, send email to
For more options, visit this group at