grpc fails to build on x64-windows

[dzenanz]

Root cause: project grpc_plugin_support is built only as .dll, not as .lib, other projects which depend on it cannot find .lib which causes link error.

Excerpts from package-x64-windows-rel-out.log:

    14>Link:
         grpc_plugin_support.vcxproj -> C:\Libs\vcpkg\buildtrees\grpc\x64-windows-rel\Release\grpc_plugin_support.dll
       FinalizeBuildStatus:
         Deleting file "grpc_plugin_support.dir\Release\grpc_plu.8D5D7D3B.tlog\unsuccessfulbuild".
         Touching "grpc_plugin_support.dir\Release\grpc_plu.8D5D7D3B.tlog\grpc_plugin_support.lastbuildstate".
    14>Done Building Project "C:\Libs\vcpkg\buildtrees\grpc\x64-windows-rel\grpc_plugin_support.vcxproj" (default targets).

    20>Link:
         C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\x86_amd64\link.exe /ERRORREPORT:QUEUE /OUT:"C:\Libs\vcpkg\buildtrees\grpc\x64-windows-rel\Release\grpc_objective_c_plugin.exe" /INCREMENTAL:NO /NOLOGO kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib "C:\Libs\vcpkg\installed\x64-windows\lib\libprotoc.lib" Release\grpc_plugin_support.lib "C:\Libs\vcpkg\installed\x64-windows\lib\libprotoc.lib" "C:\Libs\vcpkg\installed\x64-windows\lib\libprotobuf.lib" "C:\Libs\vcpkg\installed\x64-windows\lib\zlib.lib" /MANIFEST /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /manifest:embed /DEBUG /PDB:"C:/Libs/vcpkg/buildtrees/grpc/x64-windows-rel/Release/grpc_objective_c_plugin.pdb" /SUBSYSTEM:CONSOLE /OPT:REF /OPT:ICF /TLBID:1 /DYNAMICBASE /NXCOMPAT /IMPLIB:"C:/Libs/vcpkg/buildtrees/grpc/x64-windows-rel/Release/grpc_objective_c_plugin.lib" /MACHINE:X64  /machine:x64 grpc_objective_c_plugin.dir\Release\objective_c_plugin.obj
    18>LINK : fatal error LNK1181: cannot open input file 'Release\grpc_plugin_support.lib' [C:\Libs\vcpkg\buildtrees\grpc\x64-windows-rel\grpc_csharp_plugin.vcxproj]
    22>Done Building Project "C:\Libs\vcpkg\buildtrees\grpc\x64-windows-rel\grpc_ruby_plugin.vcxproj" (default targets) -- FAILED.
    18>Done Building Project "C:\Libs\vcpkg\buildtrees\grpc\x64-windows-rel\grpc_csharp_plugin.vcxproj" (default targets) -- FAILED.
    19>LINK : fatal error LNK1181: cannot open input file 'Release\grpc_plugin_support.lib' [C:\Libs\vcpkg\buildtrees\grpc\x64-windows-rel\grpc_node_plugin.vcxproj]
    20>LINK : fatal error LNK1181: cannot open input file 'Release\grpc_plugin_support.lib' [C:\Libs\vcpkg\buildtrees\grpc\x64-windows-rel\grpc_objective_c_plugin.vcxproj]

[dzenanz]

The same thing happens with the newest commit, def69b30756c9fb043f9b807b5c4156f6859c80c.

[dzenanz]

The latest 1.0.x branch (commit e05c76591acc488a5c52af25786aadd659b298f7) has an error during CMake config step:

CMake Error at CMakeLists.txt:68 (add_subdirectory):
  The source directory

    C:/Libs/vcpkg/buildtrees/grpc/src/third_party/boringssl

  does not contain a CMakeLists.txt file.


CMake Error at CMakeLists.txt:69 (add_subdirectory):
  add_subdirectory given source
  "C:/Libs/vcpkg/buildtrees/grpc/src/third_party/protobuf/cmake" which is not
  an existing directory.


CMake Error at CMakeLists.txt:70 (add_subdirectory):
  The source directory

    C:/Libs/vcpkg/buildtrees/grpc/src/third_party/zlib

  does not contain a CMakeLists.txt file.

[KindDragon]

Probably related to #226

[dzenanz]

Yes, it looks like the same error. I will try to see if it can be fixed by a minor change to grpc.

[dzenanz]

Trying to use this trick by adding -DCMAKE_WINDOWS_EXPORT_ALL_SYMBOLS=TRUE in portfile.cmake creates a lot of link errors of this form:
message_compress.obj : error LNK2019: unresolved external symbol deflate referenced in function zlib_compress [C:\Libs\vcpkg\buildtrees\grpc\x64-windows-rel\grpc_unsecure.vcxproj]
and less errors of this form:
proto_server_reflection.obj : error LNK2001: unresolved external symbol "public: static class grpc::Status const & const grpc::Status::CANCELLED" (?CANCELLED@Status@grpc@@2AEBV12@EB) [C:\Libs\vcpkg\buildtrees\grpc\x64-windows-rel\grpc++_reflection.vcxproj]
This second kind of link errors is expected, but no the first.

Did this library (grpc) ever compile through vcpkg? If not, it should be removed from the list in the vcblog article.

[codicodi]

@dzenanz, I investigated this issue some time ago, see #444

[dzenanz]

We tried the same thing and reached the same conclusion: it is not going to work for quite some time into the future (until grpc people fix their CMake build system).

[codicodi]

I wonder why portfile says static building not supported. With a little patch that properly links zlib it should work fine, while shared ones seem problematic.

[KindDragon]

Because of protobuf #149

[dzenanz]

When they introduced the ability to make static builds in vcpkg, they added that condition which forces dynamic build for all libraries. Yes, it could be possible to try static build. grpc authors force static building on Windows in their own Visual Studio solutions.

[dzenanz]

@codicodi will you give static version a try?

[codicodi]

Well, changing dynamic override to static override seems to work (ie. it builds). But it still fails post-build checks (probably the portfile messes something up during cleanup).

[dzenanz]

Fails which post-build checks? Can you provide a log fragment and/or diff to portfile?

[codicodi]

It looks like portfile removes all the debug libs. I'll prepare PR with fix...

[alexkaratarakis]

Merged #539. Also, I noticed protobuf would sporadically fail. I made a number of builds, and the occasional failures were because:

1. The linker run out of memory
2. The build is running a separate process which is apparently not completed when vcpkg_install_cmake() returns. Therefore, the last build (debug) had the post-build checks that are mentioned above.

4ace533 is an attempt to make the build more consistent.

[dzenanz]

Thanks @alexkaratarakis! #539 fixes the build issue.

However, when I try to build my project which depends on gRPC, I get link errors to its dependencies (zlib and OpenSSL):

2>------ Build started: Project: display, Configuration: Debug x64 ------
2>grpc++.lib(message_compress.obj) : error LNK2019: unresolved external symbol deflate referenced in function zlib_compress
...
2>grpc++.lib(message_compress.obj) : error LNK2019: unresolved external symbol inflateInit2_ referenced in function zlib_decompress
2>grpc.lib(ssl_transport_security.obj) : error LNK2019: unresolved external symbol sk_num referenced in function peer_from_x509
...
2>grpc.lib(ssl_transport_security.obj) : error LNK2019: unresolved external symbol SSL_set_info_callback referenced in function create_tsi_ssl_handshaker
2>grpc.lib(ssl_transport_security.obj) : error LNK2019: unresolved external symbol SSL_state referenced in function NullVerifyCallback
2>grpc.lib(ssl_transport_security.obj) : error LNK2019: unresolved external symbol GENERAL_NAME_free referenced in function peer_from_x509
2>C:\path\bin\Debug\display.exe : fatal error LNK1120: 82 unresolved externals

And the probable reason for not having protobuf link errors is that our project directly depends on protobuf too (in addition to gRPC).

I will try building static versions of zlib and OpenSSL and see whether that helps.

[dzenanz]

Building ("installing") static version of grpc and its dependencies does not resolve the linking problem. Explicitly adding zlib and openssl as linker inputs enables our project to build and run. Is this the expected behavior?

[ras0219-msft]

That's definitely not the expected behavior; linking zlib and openssl should have been done automatically for you.

Are you using the user wide integration or the NuGet package based integration? In the case of the NuGet package, did you add the same package to each of your projects?

Edit: Additionally, do you have "inherit from project defaults" checked? Unchecking that box will suppress our automatic linkage.

[dzenanz]

I was relying on user-wide integration. I did not try NuGet packages. The reason I am trying vcpkg is because with a CMake-based project, I have to manually uninstall and then install NuGet packages each time VS solution is regenerated by CMake (which happens frequently as this project is under development).

Edit: I did not fiddle with "inherit from project defaults", I think it was on (as usual).

[ras0219-msft]

Ah, then that is the issue -- sorry, I jumped to the conclusion above that you were using just MSBuild.

We attempt to be a good CMake citizen by following the CMake paradigm of find_package()/find_library()/find_path() and not changing the experience too much from other platforms. So, you will need to add the appropriate search commands to your CMakeLists.txt:

find_package(ZLIB REQUIRED)
find_package(OpenSSL REQUIRED)

target_link_libraries(myapplication ${ZLIB_LIBRARIES} ${OPENSSL_LIBRARIES})
target_include_directories(myapplication ${ZLIB_INCLUDE_DIR} ${OPENSSL_INCLUDE_DIR})

[dzenanz]

That works with static build. Thanks @ras0219-msft !

target_include_directories is not needed since our project does not use zlib nor openssl directly.