Can you provide a minimal reproduction for the problem?
(include commands to run as a preparation and a simple C++ project that
demonstrates the issue.)
You're right in the sense that you need to run grpc_init() before using
gRPC in C++. There might be other problems in your code, but it's hard to
know without seeing the actual code you run and the exact way you build.
On Wednesday, November 27, 2019 at 7:54:13 PM UTC+1, Stéphane Charette
wrote:
>
> 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/154eb3e2-8c6e-4a47-a523-c2fd204d4742%40googlegroups.com.
