I'm writing a plugin for a Windows app. I need grpc and protobufs to be
statically linked into my plugin's dll.
In vcpkg, I created a new triplet to build static libs but dynamically
linked with the runtime using /MD instead of /MT. My triplet looks like
this:
>*type c:\src\vcpkg\triplets\x64-windows-mixed.cmake*
set(VCPKG_TARGET_ARCHITECTURE x64)
set(VCPKG_CRT_LINKAGE dynamic)
set(VCPKG_LIBRARY_LINKAGE static)
And then I installed grpc and protobufs like this:
*vcpkg.exe install c-ares:x64-windows-mixed grpc:x64-windows-mixed
openssl:x64-windows-mixed openssl-windows:x64-windows-mixed
protobuf:x64-windows-mixed zlib:x64-windows-mixed*
I link everything (protobuf::libprotoc protobuf::libprotobuf
protobuf::libprotobuf-lite gRPC::gpr gRPC::grpc gRPC::grpc++
gRPC::grpc_cronet c-ares::cares c-ares::cares_static OpenSSL::SSL
OpenSSL::Crypto ZLIB::ZLIB) into my .dll, and when it comes time to run the
code, I get one of two problems.
*Problem #1: Cannot resolve "localhost":*
E1127 10:17:30.456000000 496 resolver_registry.cc:80] don't know how to
resolve 'localhost:56765' or 'dns:///localhost:56765'
E1127 10:17:30.457000000 496 resolver_registry.cc:80] don't know how to
resolve 'dns:///localhost:56765' or 'dns:///dns:///localhost:56765'
E1127 10:17:30.458000000 496 channel.cc:83] channel stack builder failed:
{"created":"@1574878650.457000000","description":"the target uri is not
valid.","file":"C:\src\vcpkg\buildtrees\grpc\src\v1.23.1-ebfd5c51df\src\core\ext\filters\client_channel\client_channel.cc","file_line":1483}
E1127 10:17:30.459000000 496 channel_connectivity.cc:50]
grpc_channel_check_connectivity_state called on something that is not a
client channel, but 'lame-client'
STATE=channel has seen a failure that it cannot recover from
Found what I think is the solution to that here:
https://github.com/grpc/grpc/issues/11366 Because I'm create static libs,
apparently I need to manually call grpc_init().
*Problem #2: Memory corruption.*
As soon as I make that call to grpc_init(), memory is hosed. In a debugger
I see a segfault with no backtrace making me think the heap and/or stack is
now completely hosed. Considering how difficult of a time I've had trying
to figure out how to build and link the dependencies into my .dll, I
wouldn't be surprised if it is a "simple" compiler switch that I need to
set, but at this point I have no idea where to go next.
Anyone have thoughts on what might be happening?
Stéphane Charette
--
You received this message because you are subscribed to the Google Groups
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/grpc-io/2aa54985-5e08-4336-a01d-68cf7652d2c6%40googlegroups.com.
