How to build Google’s protobuf in Windows using MinGW?
I’m using Codeblocks as my IDE with MingGW. I’m trying to use google protocol buffers, but I’m having trouble building the protobuf.
The readme file for protobuf says:
If you are using Cygwin or MinGW, follow the Unix installation instructions, above.
The Unix instructions says:
To build and install the C++ Protocol Buffer runtime and the Protocol Buffer compiler (protoc) execute the following: $ ./configure $ make $ make check $ make install
I don’t know how to perform these in Windows because «configure» is a Unix script and I don’t know how to execute it, or the rest of the commands.
Can someone explain in more detail how I can build protobuf using MinGW on Windows?
3 Answers 3
Here’s what worked for me:
You need to install MSYS with mingw. This is a minimal unix-like shell environment that lets you configure/make most unix packages. Read the mingw docs on how to install that (either with mingw-get or the GUI installer).
Once you have installed MSYS, you should have a shortcut in your start menu, named «MinGW Shell». That opens a console with a bash.
Extract the source tarball to your MSYS home directory. I have mingw installed in «D:\prog», so the directory was «D:\prog\MinGW\msys\1.0\home\ «. You can tell your MSYS username from the shell prompt. When done, you should have a directory «D:\prog\MinGW\msys\1.0\home\ \protobuf-2.4.1».
At the shell prompt, change to the protobuf directory:
Run the configure script (note the backquotes):
./configure —prefix=`cd /mingw; pwd -W`
The —prefix paramater makes sure protobuf is installed in the mingw directory tree instead of the MSYS directories, so you can build outside the MSYS shell (e.g. with CodeBlocks. )
That’s it. You should now be able to compile your project with protobuf.
You should be able to:
- call protoc from your project/makefiles
- #include etc.
- link with -lprotobuf or -lprotobuf-lite
Edit: Bringing this a bit more up to date. I tried setting up a new PC with current versions of MinGW and protobuf 2.5.0, and these are the problems I had:
There is no «MinGW Shell» shortcut in the start menu.
For some reason current MinGW installations fail to install that.
But there is a msys.bat in \msys\1.0 which brings up a console with a bash. Create a shortcut to that batch file somewhere.
gcc does not work from the MSYS shell.
I had to run a post-installation batch file manually and answer the questions there. This sets up fstab entries that mount the mingw directories in the MSYS environment.
You need to run \msys\1.0\postinstall\pi.bat
My Avira antivirus interfered with the protobuf compilation.
It complained about the generated protoc.exe being a «TR/Crypt.XPACK.Gen» trojan and blocked acces to that file, resulting in a corrupted build.
I got error messages saying something like protoc:./.libs/lt-protoc.c:233: FATAL: couldn’t find protoc. when trying to start protoc.
I had to disable the Avira realtime scanner and make clean && make && make install again
This post has aged quite a bit, and mingw does not equal mingw anymore. In this day and age, I would rather recommend MSYS2 which comes with a port of ArchLinux’s pacman package manager, a recent, better-working (c++11 std::thread support!) mingw fork for both 32 and 64 bit, and a protobuf package that you just need to install and be good.
Protobuf build windows msvc
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
protobuf / src / README.md
8 contributors
Users who have contributed to this file
Protocol Buffers — Google’s data interchange format
Copyright 2008 Google Inc.
C++ Installation — Unix
To build protobuf from source, the following tools are needed:
On Ubuntu/Debian, you can install them with:
On other platforms, please use the corresponding package managing tool to install them before proceeding.
To get the source, download one of the release .tar.gz or .zip packages in the release page:
For example: if you only need C++, download protobuf-cpp-[VERSION].tar.gz ; if you need C++ and Java, download protobuf-java-[VERSION].tar.gz (every package contains C++ source already); if you need C++ and multiple other languages, download protobuf-all-[VERSION].tar.gz .
You can also get the source by «git clone» our git repository. Make sure you have also cloned the submodules and generated the configure script (skip this if you are using a release .tar.gz or .zip package):
To build and install the C++ Protocol Buffer runtime and the Protocol Buffer compiler (protoc) execute the following:
If «make check» fails, you can still install, but it is likely that some features of this library will not work correctly on your system. Proceed at your own risk.
For advanced usage information on configure and make, please refer to the autoconf documentation:
Hint on install location
By default, the package will be installed to /usr/local. However, on many platforms, /usr/local/lib is not part of LD_LIBRARY_PATH. You can add it, but it may be easier to just install to /usr instead. To do this, invoke configure as follows:
If you already built the package with a different prefix, make sure to run «make clean» before building again.
Compiling dependent packages
To compile a package that uses Protocol Buffers, you need to pass various flags to your compiler and linker. As of version 2.2.0, Protocol Buffers integrates with pkg-config to manage this. If you have pkg-config installed, then you can invoke it to get a list of flags like so:
Note that packages written prior to the 2.2.0 release of Protocol Buffers may not yet integrate with pkg-config to get flags, and may not pass the correct set of flags to correctly link against libprotobuf. If the package in question uses autoconf, you can often fix the problem by invoking its configure script like:
This will force it to use the correct flags.
If you are writing an autoconf-based package that uses Protocol Buffers, you should probably use the PKG_CHECK_MODULES macro in your configure script like:
See the pkg-config man page for more info.
If you only want protobuf-lite, substitute «protobuf-lite» in place of «protobuf» in these examples.
Note for Mac users
For a Mac system, Unix tools are not available by default. You will first need to install Xcode from the Mac AppStore and then run the following command from a terminal:
To install Unix tools, you can install «port» following the instructions at https://www.macports.org . This will reside in /opt/local/bin/port for most Mac installations.
Then follow the Unix instructions above.
Note for cross-compiling
The makefiles normally invoke the protoc executable that they just built in order to build tests. When cross-compiling, the protoc executable may not be executable on the host machine. In this case, you must build a copy of protoc for the host machine first, then use the —with-protoc option to tell configure to use it instead. For example:
This will use the installed protoc (found in your $PATH) instead of trying to execute the one built during the build process. You can also use an executable that hasn’t been installed. For example, if you built the protobuf package for your host machine in ../host, you might do:
Either way, you must make sure that the protoc executable you use has the same version as the protobuf source code you are trying to use it with.
Note for Solaris users
Solaris 10 x86 has a bug that will make linking fail, complaining about libstdc++.la being invalid. We have included a work-around in this package. To use the work-around, run configure as follows:
See src/solaris/libstdc++.la for more info on this bug.
Note for HP C++ Tru64 users
To compile invoke configure as follows:
Also, you will need to use gmake instead of make.
Note for AIX users
Compile using the IBM xlC C++ compiler as follows:
Also, you will need to use GNU make ( gmake ) instead of AIX make .
C++ Installation — Windows
If you only need the protoc binary, you can download it from the release page:
In the downloads section, download the zip file protoc-$VERSION-win32.zip. It contains the protoc binary as well as public proto files of protobuf library.
Protobuf and its dependencies can be installed directly by using vcpkg :
If zlib support is desired, you’ll also need to install the zlib feature:
To build from source using Microsoft Visual C++, see cmake/README.md.
To build from source using Cygwin or MinGW, follow the Unix installation instructions, above.
Binary Compatibility Warning
Due to the nature of C++, it is unlikely that any two versions of the Protocol Buffers C++ runtime libraries will have compatible ABIs. That is, if you linked an executable against an older version of libprotobuf, it is unlikely to work with a newer version without re-compiling. This problem, when it occurs, will normally be detected immediately on startup of your app. Still, you may want to consider using static linkage. You can configure this package to install static libraries only using:
The complete documentation for Protocol Buffers is available via the web at:
Errors when linking to protobuf 3 on MS Visual C
Encountered on Visual Studio 2013, but it’s reproducible with any version.
I cloned the protocol buffer library from github, ran CMake-gui on it (I left everything to default, so it’s the static version), only built libprotobuf (other project failed for some reason, cmd.exe error, might have something to do with tests, but libprotobuf builds fine).
My project uses headers generated with the .proto file found on the mapbox vector tiles spec’s github.
When I link, I first have this error
Error 1 error C4996: ‘std::_Copy_impl’: Function call with parameters that may be unsafe — this call relies on the caller to check that the passed values are correct. To disable this warning, use -D_SCL_SECURE_NO_WARNINGS. See documentation on how to use Visual C++ ‘Checked Iterators’ s:\program files (x86)\microsoft visual studio 12.0\vc\include\xutility
I tried disabling it with -D_SCL_SECURE_NO_WARNINGS in additional command line arguments, but then I have other errors:
Error 1 error LNK2038: mismatch detected for ‘RuntimeLibrary’: value ‘MTd_StaticDebug’ doesn’t match value ‘MDd_DynamicDebug’ in main.obj S:\eiogit3\misc-projs\mapload\mapload\libprotobufd.lib(common.obj)
1 Answer 1
It’s a mismatch of how the VStudio C (and C++) RunTime Library (VCRTLib or UCRT — check [SO]: How to circumvent Windows Universal CRT headers dependency on vcruntime.h (@CristiFati’s answer)) is used by your project and by libprotobuf project. Let me detail:
Let’s say there’s some C (C++) code. The purpose of that code is to be run. Than can be achieved:
- Directly: including that code in an VC Application type project — which will generate an .exe
- Indirectly: including the code in an VC Library type project — which will generate a library which will only be able to run when called from another .exe (that calls that library). The library can be:
- static: all the C (C++) code will be compiled and stored in a .lib file. You will need that file when using the library in another project (whether it’s an application or a library) — at link time. Note that all the needed code from your .lib will be «copied» into the other project
- dynamic: you will have 2 files now: a .dll file which will contain the compiled (and linked) code, and a .lib file (1) which will contain «pointers» (if you will) to the code in the .dll file. When using the library in another project, you will also need the .lib file at link time, but now it won’t contain the code so it won’t be copied in the other library (the other library will be smaller), but at runtime the other library will need the .dll file
You can check [SO]: LNK2005 Error in CLR Windows Form (@CristiFati’s answer) for details of how C (C++) code gets to be transformed in executable format. Also Google is full of articles about differences between static and dynamic libraries, when to use one or the other, an example can be found on [SO]: When to use dynamic vs. static libraries.
As you guessed, the CRT or C RunTime library (that contains the underlying system that makes C code able to run — one example are memory management functions: malloc, free) makes no exception — it’s the equivalent of Nix‘s libc.a (static or archive) vs. libc.so (dynamic or shared object) — but in VStudio it’s a little bit more complicated:
- Static CRT resides in libcmt.lib
- Dynamic CRT resides in msvcrt.lib which «points» to msvcr###.dll(2) (msvcr120.dll for VStudio 2013)
Notes:
- A «d» at the end of the library name (msvcrd.lib), means that it’s compiled with debug symbols
- C++ runtime library is under the exact situation; the names have an extra p: libcpmt.lib, msvcprt.lib, msvcp120.dll
- For more details, check [MS.Docs]: CRT Library Features
Now, UCRT parts, are not included in the project like any other lib (Project Properties -> Linker -> Input -> Additional Dependencies), but because their nature (static or dynamic) is required at compile time they are configured from: [MS.Docs]: /MD, /MT, /LD (Use Run-Time Library), where there are 4 available choices:
- Multi-threaded (/MT)
- Multi-threaded Debug (/MTd)
- Multi-threaded DLL (/MD)
- Multi-threaded Debug DLL (/MDd)
Obviously, the ones that contain «Debug» are when building for Debug configuration while the other ones for Release; the key point is that the ones that have DLL are using the dynamic runtime version, while the other ones the static version.
Back to your error: the linker complains that main.obj (part of your project) has MDd_DynamicDebug (linking against the dynamic debug version), while common.obj (part of libprotobuf project) has MTd_StaticDebug (linking against the static debug version), so you link against 2 runtimes in the same executable (or .dll) — which is not possible.
In order to fix it, you should make sure that both libprotobuf and your main project have the same value for UCRT.
Of course it’s simpler to change your main project setting to match libprotobuf‘s one, but it’s recommended to use the dynamic runtime version (things can get messy in larger projects that have .dlls involved) even if this requires to recompile libprotobuf (well, if changing that option generates errors that make libprotobuf very hard to build, and your project is going to stay this simple, you can use the static UCRT).
Note: Not to mistake UCRT type (static / dynamic) with the way libprotobuf is being built (static at this point, but I’m sure that it can be built as dynamic too).
Update #0
Adding some additional info on the above note, as some comments requested it, and it might be useful to other users.
There are 2 aspects about a library (including libprotobuf), that are totally unrelated:
- Library type (the way it is being built): dynamic / static
- UCRT type (the way it uses UCRT): again, dynamic / static
So, there are 4 perfectly valid combinations:
- Dynamic library using dynamic UCRT
- Dynamic library using static UCRT
- Static library using dynamic UCRT
- Static library using static UCRT
For libprotobuf, each of the aspects is controlled by a boolean cmake option:
- Library type: protobuf_BUILD_SHARED_LIBS
- UCRT type: protobuf_MSVC_STATIC_RUNTIME
The 2 flags can be set by either:
- cmake-gui
- cmake cmdline (passing them as arguments — e.g.: -Dprotobuf_BUILD_SHARED_LIBS=OFF -Dprotobuf_MSVC_STATIC_RUNTIME=OFF )
The above 4 combinations are thus possible (at least in v3.5), but #2. is disabled by default (specifying -Dprotobuf_BUILD_SHARED_LIBS=ON -Dprotobuf_MSVC_STATIC_RUNTIME=ON will build a .dll which will link to the dynamic UCRT), in order to avoid possible runtime problems, and enabling it requires manual intervention.
Footnotes
#1: The .lib file will only be created if the library exports symbols, as it wouldn’t make sense otherwise (nothing needed at link time, and the .dll will be created, but pretty much unusable)
#2: For newer VStudio versions (starting with v2015), the msvcr(t) part has been replaced by vcruntime (or at least this is the entrypoint, as it was split in smaller logical pieces (check the URL at the beginning))