Problem with linking runtime libraries on Windows for C++

[wayne....@gmail.com]

Hi,
I am trying to use Google Protocol Buffers run time libraries in my
application. To use Protocol Buffers, I need to first build the run-
time libraries for C++ on Windows. I am using Visual Studio 2003.

While linking the libraries into my application I get the following
errors. Can anyone help me figure out what might be the issue?

libprotobuf.lib(zero_copy_stream_impl.obj) : error LNK2019: unresolved
external symbol __imp__close referenced in function "int __cdecl
google::protobuf::io::`anonymous namespace'::close_no_eintr(int)" (?
close_no_eintr@?
A0x29e80b4e@io@protobuf@google@@YAHH@Z)
libprotobuf.lib(zero_copy_stream_impl.obj) : error LNK2019: unresolved
external symbol __imp__read referenced in function "public: virtual
int __thiscall
google::protobuf::io::FileInputStream::CopyingFileInputStream::Read
(void *,int)" (?
Read@CopyingFileInputStream@FileInputStream@io@protobuf@google@@UAEHPAXH@Z)
libprotobuf.lib(zero_copy_stream_impl.obj) : error LNK2019: unresolved
external symbol __imp__write referenced in function "public: virtual
bool __thiscall
google::protobuf::io::FileOutputStream::CopyingFileOutputStream::Write
(void const *,int)" (?
Write@CopyingFileOutputStream@FileOutputStream@io@protobuf@google@@UAE_NPBXH@Z)

[Kenton Varda]

When you compile your app, are you making sure to use the same C runtime library against which you compiled libprotobuf?  It looks like it's complaining about missing functions in the C runtime.

[Wayne Menezes]

Thanks for yoru response!

I found that Microsoft Visual Studio was using the /MDd flag while compiling libprotobuf.lib. I changed it to use /MD which is what I am using to build my application. So now both are using the same flags, but I am still seeing the same error. I am linking the application against msvcrt.lib and msvcprt.lib which is what MSDN suggests for the /MD flag.


Wayne

[Kenton Varda]

/MDd is the debug library.  libprotobuf.lib only links against it when built in debug mode.  Are you also compiling your app in debug mode?  You need to make sure to compile both projects in the same mode.

Are you able to build the tests that come with the protobuf code?  If so, maybe check what's different between the tests project and your project.

Otherwise, I don't have any other ideas.

[Wayne Menezes]

Kenton,
I solved the issue. The problem is that in your source code there are references to functions read, write and close which are the old POSIX versions. Microsoft has deprecated these functions in favor of the ISO compliant ones namely _read _write and _close.  See http://msdn.microsoft.com/en-us/library/ms235412(VS.80).aspx
I had to change the function calls in zero_copy_stream_impl.cc to use the newer '_' versions and then the linker errors went away while building my application. I didnt find any other places where the older references were being used.

I think you need to update your source to handle this issue.

Thanks,
Wayne

[Kenton Varda]

You said you were using VS2003.  According to your link, these functions were not even "deprecated" until VS2005, and they continue to work fine in VS2008.  So I'm confused why you're seeing a problem with this.  I haven't heard anyone mention this issue before.  Is it possible your CRT headers don't match with the CRT library version that you are linking against?

I am not sure what Microsoft means by "ISO complaint".  The entire win32 API is not "ISO compliant" but I don't see them adding underscores to all of those functions.  It seems to me that they are just trying to discourage people from using portable APIs.

[Wayne Menezes]

I was using newer run time libraries than VS2003 to build my application, whilst using VS2003 to build the libraries. Sorry about the confusion.

-Wayne

[Kenton Varda]

OK, I'll put it on my TODO to add explicit #defines to work around this problem in the next version, like:

#ifdef _MSC_VER

#define close(params) _close(params)

...

#endif

Feel free to submit a patch if you want it sooner.