I had something similar (many-many strange problems) until I've removed
gRPC::grpc_cronet from the link list.
On Thursday, December 5, 2019 at 5:50:55 AM UTC-8, Jan Tattermusch wrote:
>
> 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/56bb23ec-eef6-4d73-9ea4-472da08c2702%40googlegroups.com.
