tikv/grpc-rs

The gRPC library for Rust built on C Core library and futures

Website | Documentation | Community Chat

TiKV is an open-source, distributed, and transactional key-value database. Unlike other traditional NoSQL systems, TiKV not only provides classical key-value APIs, but also transactional APIs with ACID compliance. Built in Rust and powered by Raft, TiKV was originally created by PingCAP to complement TiDB, a distributed HTAP database compatible with the MySQL protocol.

The design of TiKV ('Ti' stands for titanium) is inspired by some great distributed systems from Google, such as BigTable, Spanner, and Percolator, and some of the latest achievements in academia in recent years, such as the Raft consensus algorithm.

If you're interested in contributing to TiKV, or want to build it from source, see CONTRIBUTING.md.

TiKV is a graduated project of the Cloud Native Computing Foundation (CNCF). If you are an organization that wants to help shape the evolution of technologies that are container-packaged, dynamically-scheduled and microservices-oriented, consider joining the CNCF. For details about who's involved and how TiKV plays a role, read the CNCF announcement.

---

With the implementation of the Raft consensus algorithm in Rust and consensus state stored in RocksDB, TiKV guarantees data consistency. Placement Driver (PD), which is introduced to implement auto-sharding, enables automatic data migration. The transaction model is similar to Google's Percolator with some performance improvements. TiKV also provides snapshot isolation (SI), snapshot isolation with lock (SQL: SELECT ... FOR UPDATE), and externally consistent reads and writes in distributed transactions.

TiKV has the following key features:

• Geo-Replication

  TiKV uses Raft and the Placement Driver to support Geo-Replication.

• Horizontal scalability

  With PD and carefully designed Raft groups, TiKV excels in horizontal scalability and can easily scale to 100+ TBs of data.

• Consistent distributed transactions

  Similar to Google's Spanner, TiKV supports externally-consistent distributed transactions.

• Coprocessor support

  Similar to HBase, TiKV implements a coprocessor framework to support distributed computing.

• Cooperates with TiDB

  Thanks to the internal optimization, TiKV and TiDB can work together to be a compelling database solution with high horizontal scalability, externally-consistent transactions, support for RDBMS, and NoSQL design patterns.

Governance

See Governance.

Documentation

For instructions on deployment, configuration, and maintenance of TiKV,see TiKV documentation on our website. For more details on concepts and designs behind TiKV, see Deep Dive TiKV.

Note:

We have migrated our documentation from the TiKV's wiki page to the official website. The original Wiki page is discontinued. If you have any suggestions or issues regarding documentation, offer your feedback here.

TiKV adopters

You can view the list of TiKV Adopters.

TiKV software stack

• Placement Driver: PD is the cluster manager of TiKV, which periodically checks replication constraints to balance load and data automatically.
• Store: There is a RocksDB within each Store and it stores data into the local disk.
• Region: Region is the basic unit of Key-Value data movement. Each Region is replicated to multiple Nodes. These multiple replicas form a Raft group.
• Node: A physical node in the cluster. Within each node, there are one or more Stores. Within each Store, there are many Regions.

When a node starts, the metadata of the Node, Store and Region are recorded into PD. The status of each Region and Store is reported to PD regularly.

Quick start

Deploy a playground with TiUP

The most quickest to try out TiKV with TiDB is using TiUP, a component manager for TiDB.

You can see this page for a step by step tutorial.

Deploy a playground with binary

TiKV is able to run separately with PD, which is the minimal deployment required.

1. Download and extract binaries.

$ export TIKV_VERSION=v7.5.0
$ export GOOS=darwin  # only {darwin, linux} are supported
$ export GOARCH=amd64 # only {amd64, arm64} are supported
$ curl -O  https://tiup-mirrors.pingcap.com/tikv-$TIKV_VERSION-$GOOS-$GOARCH.tar.gz
$ curl -O  https://tiup-mirrors.pingcap.com/pd-$TIKV_VERSION-$GOOS-$GOARCH.tar.gz
$ tar -xzf tikv-$TIKV_VERSION-$GOOS-$GOARCH.tar.gz
$ tar -xzf pd-$TIKV_VERSION-$GOOS-$GOARCH.tar.gz

2. Start PD instance.

$ ./pd-server --name=pd --data-dir=/tmp/pd/data --client-urls="http://127.0.0.1:2379" --peer-urls="http://127.0.0.1:2380" --initial-cluster="pd=http://127.0.0.1:2380" --log-file=/tmp/pd/log/pd.log

3. Start TiKV instance.

$ ./tikv-server --pd-endpoints="127.0.0.1:2379" --addr="127.0.0.1:20160" --data-dir=/tmp/tikv/data --log-file=/tmp/tikv/log/tikv.log

4. Install TiKV Client(Python) and verify the deployment, required Python 3.5+.

$ pip3 install -i https://test.pypi.org/simple/ tikv-client

from tikv_client import RawClient

client = RawClient.connect("127.0.0.1:2379")

client.put(b'foo', b'bar')
print(client.get(b'foo')) # b'bar'

client.put(b'foo', b'baz')
print(client.get(b'foo')) # b'baz'

Deploy a cluster with TiUP

You can see this manual of production-like cluster deployment presented by @c4pt0r.

Build from source

See CONTRIBUTING.md.

Client drivers

• Go (The most stable and widely used)
• Java
• Rust
• C

If you want to try the Go client, see Go Client.

Security

Security audit

A third-party security auditing was performed by Cure53. See the full report here.

Reporting Security Vulnerabilities

To report a security vulnerability, please send an email to TiKV-security group.

See Security for the process and policy followed by the TiKV project.

Communication

Communication within the TiKV community abides by TiKV Code of Conduct. Here is an excerpt:

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.

Social Media

• Twitter
• Blog
• Reddit
• Post questions or help answer them on Stack Overflow

Slack

Join the TiKV community on Slack - Sign up and join channels on TiKV topics that interest you.

License

TiKV is under the Apache 2.0 license. See the LICENSE file for details.

Acknowledgments

• Thanks etcd for providing some great open source tools.
• Thanks RocksDB for their powerful storage engines.
• Thanks rust-clippy. We do love the great project.

grpc-rs's Issues

Proposal: rewrite all ABI with custom prefix

There are both grpc_xxx and grpcwrap_xxx styles ABI in grpc_sys/src/lib.rs. We only add grpcwrap prefix to the ABI written by ourselves. It's clean and simple.

However, upstream sometimes can change the signature of a public ABI without changing its name. Unfortunately, because the name is the same, so the mismatch can't be detected at link time. So it can lead to unexpected behavior. #129 is an example. Upstream changes the signature and usage of alarm, but the crate can still be compiled and linked successfully.

So I propose to rewrite all ABIs in used by adding a grpcwrap_ prefix. That way we can ensure signature won't be changed unexpectedly. And upstream changes can also be detected by C/C++ compilers at compile time.

grpcio-sys requires go?

On two separate systems, compilation of sys fails when go is not installed.

The readme does not seem to indicate this is a requirement, am I doing something wrong here?

I would really prefer not to have go installed for compilation on my dev machine, is it possible?

client sometimes don't receive server streaming messages

If I run the following code multiple times, it sometimes don't receive a response. Also I'm not sure why there's always a cancelled error.

log with response:

     Running `target/debug/grpc-client`
response: value: "test"
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: RpcFailure(RpcStatus { status: Cancelled, details: Some("Cancelled") })', libcore/result.rs:945:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.

log without response:

     Running `target/debug/grpc-client`
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: RpcFailure(RpcStatus { status: Cancelled, details: Some("Cancelled") })', libcore/result.rs:945:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.

grpcio 0.2.1
grpcio-proto 0.2.0
same thing with 3110b36
rustc 1.26.0-nightly (2789b067d 2018-03-06)
Arch Linux

proto

syntax = "proto3";

package testcase;

message Empty {}

service TestCase {
  rpc Sub(Empty) returns (stream Notification) {}
}

message Notification {
  string value = 1;
}

server

extern crate futures;
extern crate grpcio;
extern crate grpcio_proto;
extern crate protobuf;

mod testcase;
mod testcase_grpc;

use testcase::{Empty, Notification};
use testcase_grpc::{create_test_case, TestCase};

use futures::sync::oneshot;
use futures::{Future, Sink};
use grpcio::{Environment, RpcContext, ServerBuilder, ServerStreamingSink, WriteFlags};

use std::io::Read;
use std::sync::Arc;
use std::{io, thread};

#[derive(Clone)]
struct TestService;

impl TestCase for TestService {
    fn sub(&self, ctx: RpcContext, _req: Empty, sink: ServerStreamingSink<Notification>) {
        println!("sub");

        let mut n = Notification::new();
        n.set_value("test".to_string());
        let f = sink.send((n, WriteFlags::default()))
            .map(|_sink| ())
            .map_err(|e| panic!(e));

        ctx.spawn(f);
    }
}

fn main() {
    let env = Arc::new(Environment::new(1));
    let service = create_test_case(TestService);
    let mut server = ServerBuilder::new(env)
        .register_service(service)
        .bind("127.0.0.1", 50051)
        .build()
        .unwrap();
    server.start();
    for &(ref host, port) in server.bind_addrs() {
        println!("listening on {}:{}", host, port);
    }
    let (tx, rx) = oneshot::channel();
    thread::spawn(move || {
        println!("Press ENTER to exit...");
        let _ = io::stdin().read(&mut [0]).unwrap();
        tx.send(())
    });
    let _ = rx.wait();
    let _ = server.shutdown().wait();
}

client

extern crate futures;
extern crate grpcio;
extern crate grpcio_proto;
extern crate protobuf;

mod testcase;
mod testcase_grpc;

use testcase::Empty;
use testcase_grpc::TestCaseClient;

use futures::{Future, Stream};
use grpcio::{ChannelBuilder, EnvBuilder};

use std::sync::Arc;

fn main() {
    let env = Arc::new(EnvBuilder::new().build());
    let ch = ChannelBuilder::new(env).connect("127.0.0.1:50051");

    let client = TestCaseClient::new(ch);

    let req = Empty::new();
    let stream = client.sub(&req).expect("rpc");

    let t = stream.for_each(|response| {
        println!("response: {:?}", response);
        Ok(())
    });

    t.wait().unwrap();
}

install instruction is out of date and can't work

Now after we update protobuf to 2.0, the install instruction can't work now.

 cargo install protobuf
    Updating registry `https://github.com/rust-lang/crates.io-index`
  Installing protobuf v2.0.2
error: specified package has no binaries

Setting max message len seems to have no affect

Using channel builder, if I set max message len and max receive len to usize max, for example, it does not appear to be respected and the default of 4MB limit is hit for messages larger than 4MB

Looking at the source everything seems to be in order, the options are iterated and set, etc.

Nevertheless I still cannot seem to increase the max message size

port unit test from csharp module of c-grpc

Threads / workers seem to be blocking each other

(question cross-posted to reddit)

Test repo

I can't seem to work out how to use gRPC (using the grpcio crate, grpc-rs). I have a dummy server that just sleeps for a bit and then generates a random number and sends it back, but it seems that the routine is blocking the whole server. I was originally under the impression that Environment::new(8) generated a thread pool of 8 threads, and that it performed some sort of work-stealing routing to avoid blocking. But maybe I have to organize my own thread pool myself?

Essentially, my server is very simple (full source at the link above):

fn spread_chaos(&self, ctx: RpcContext, req: ChaosRequest, sink: UnarySink<ChaosResponse>) {
    println!("received a thing");
    // TODO: There's no guarantee this won't collide
    thread::sleep_ms(1000);
    let id = rand::thread_rng().gen::<u64>();
    let mut resp = ChaosResponse::new();
    resp.set_id(id);
    let f = sink.success(resp)
        .map_err(move |e| println!("failed to reply {:?}: {:?}", req, e));
    ctx.spawn(f);
}

That just prints a thing, sleeps for a bit, and then returns. My main function looks very similar to the example:

fn main() {
    let env = Arc::new(Environment::new(8));
    let service = create_chaos(ChaosService);
    let mut server = ServerBuilder::new(env)
        .register_service(service)
        .bind("127.0.0.1", 50051)
        .build()
        .expect("Could not create server");
    server.start();

    for &(ref host, port) in server.bind_addrs() {
        println!("listening on {}:{}", host, port);
    }

    let (tx, rx) = oneshot::channel();

    thread::spawn(move || {
        println!("press ENTER to exit...");
        let _ = io::stdin().read(&mut [0]).unwrap();
        tx.send(())
    });

    let _ = rx.wait();
    let _ = server.shutdown().wait();
}

Client Stream of a streaming server can't be Boxed

I've put a repro at https://github.com/illicitonion/grpc-rs-repro-0 which uses the proto from https://github.com/googleapis/googleapis/blob/master/google/bytestream/bytestream.proto

The call to call_sync, which doesn't move the stream out of the function, reliably works.

The call to call_future, which Boxes the stream, either gives me:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "RpcFailure(RpcStatus { status: Unknown, details: Some(\"Failed to create subchannel\") })"', src/libcore/result.rs:860:4
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
   1: std::panicking::default_hook::{{closure}}
   2: std::panicking::default_hook
   3: std::panicking::rust_panic_with_hook
   4: std::panicking::begin_panic_new
   5: std::panicking::begin_panic_fmt
   6: rust_begin_unwind
   7: core::panicking::panic_fmt
   8: core::result::unwrap_failed
   9: <core::result::Result<T, E>>::unwrap
  10: grpcrepro::main
  11: __rust_maybe_catch_panic
  12: std::rt::lang_start
  13: main

or

E1201 22:37:55.116403000 140735833875264 call.c:1731]                  assertion failed: grpc_cq_begin_op(call->cq, notify_tag)
Abort trap: 6

I believe both should be safe, and it's possible that the Stream being produced by the client isn't properly owning all of the state it needs.

Check alarm notify mechanism for all poll engine

Current notify mechanism relies on an assumption that requests for the same call is always handled by the same thread. We should check if it still holds when poll engine is changed.

Can grpcio support host or ip whitelist

As desc as title, can grpcio support host or ip whitelist function to filter out some request.

error compiling grpcio-sys on macos

running: "cc" "-O0" "-ffunction-sections" "-fdata-sections" "-fPIC" "-g" "-m64" "-I" "grpc/include" "-Wall" "-Wextra" "-Werror" "-o" "/Users/knightmare/Soft/grpc-rs/target/debug/build/grpcio-sys-49be9d5cc5a0c1c5/out/grpc_wrap.o" "-c" "grpc_wrap.c"
cargo:warning=In file included from grpc_wrap.c:56:
cargo:warning=In file included from grpc/include/grpc/support/log.h:24:
cargo:warning=/usr/local/include/stdlib.h:131:25: error: pointer is missing a nullability type specifier (_Nonnull, _Nullable, or _Null_unspecified) [-Werror,-Wnullability-completeness]
cargo:warning=double atof(const char *);
cargo:warning= ^

Run tests with sanitizer enabled

Although rust guarantee safety within safe rust, but this repository uses a lot of unsafe code, such as FFI, and raw pointer manipulation. So I think it's necessary to enable sanitizer when running tests of the project to detect possible bugs and memory corruptions.

link error on windows

libgrpcio_sys-c181e49ccc9686a4.rlib(grpc_wrap.o) : error LNK2019: unresolved external symbol grpc_set_ssl_roots_override_callback referenced in function grpcwrap_override_default_ssl_roots
libgrpcio_sys-c181e49ccc9686a4.rlib(grpc_wrap.o) : error LNK2019: unresolved external symbol grpc_ssl_credentials_create referenced in function grpcwrap_ssl_credentials_create
libgrpcio_sys-c181e49ccc9686a4.rlib(grpc_wrap.o) : error LNK2019: unresolved external symbol grpc_ssl_server_credentials_create_ex referenced in function grpcwrap_ssl_server_credentials_create
G:\projects\test-grpc-rs\target\debug\deps\test_grpc_rs-fb917f54ce759b2e.exe : fatal error LNK1120: 3 unresolved externals

grpcwrap_ssl_credentials_create, grpcwrap_override_default_ssl_roots, grpcwrap_ssl_server_credentials_create these functions should be excluded in grpc_wrap.c when using default feature(without secure), I suggest use a macro to cc to hide these functions when using default feature.

Please release a new version with the healthchecks feature

Is it possible to release a new version of this crate?

create secure connection with grpcio library occupy large memrss

Hi:
I find my app to create secure connection with grpcio library occupy large memrss (~ 60M). After code analyse, I find this appearance came from the secure-client func which is as below:

pub fn create_exchange_client() -> SecureExchangeClient {
    let host = "myhost";
    let port = "myport";
    let master = format!("{}:{}", host, port);
    let crt = "mycert";

    let ccb = ChannelCredentialsBuilder::new().root_cert(crt).build();
    let builder = EnvBuilder::new();
    let env = Arc::new(builder.build());
    let ch_env = Arc::clone(&env);
    let builder = ChannelBuilder::new(ch_env);
    let ch = builder.secure_connect(&master, ccb);
    SecureExchangeClient::new(ch)
}

How can I make this func's memrss become small?

whether this project supports cross-compiling in windows or not?

As desc in title, whether this project supports cross-compiling in windows or not?

grpc-rs fails to build on ppc64le

This is related to tikv/tikv#1965 and part of the overall effort to port tikv to ppc64le.

The specific issue here is due to the dependency on a older version of grpc, that comes from
https://github.com/pingcap/grpc

This version of grpc is not supported on ppc64le, while the current master https://github.com/grpc/grpc actually works on ppc64le (builds and passes its self-tests). grpc-rs builds fine even on ppc64le, after updating it to point to https://github.com/grpc/grpc and I was successfully able to use that build with tikv. However, this was a temporary workaround.

I would like to understand the requirements to fix this issue upstream. Towards, that end, I had a few queries:
1 - Is there a specific reason for using a fork of a specific version of grpc, rather than mainstream grpc? and would it make it challenging to keep up with the changes happening on grpc in the longer term? Do we plan to switch to using grpc up-stream at some point?
2 - Would it be acceptable if we attempt to update grpc to the latest master? I understand that there are certain commits in the forked repo, that may not be present in the up-stream grpc repo and am not sure how challenging integration might be.
3 - I would like to understand, if, apart from 1 and 2, there is a better/recommended way to handle the issue?

Thanks!

Regards,
Priya

Update futures to the version merged in std (async/await)

Context:

Futures 0.2 has been released and it requires work to upgrade. We are using 0.1: https://github.com/pingcap/grpc-rs/blob/d119e6f7f7943bc3e6910a2c5f3cd9d6b1abca28/Cargo.toml#L20

It may be preferable to wait for Futures 0.3 according to this post.

Dependencies:

• No known

Dependents:

• tikv/tikv#2845

Is there a way to detect a closed connection between sending stuff to the sink

If I try to send stuff in the sink and the connection is closed I'll get an error but I'm wondering if there's a way to detect the connection even if I don't send stuff into the sink for a long time.

I want to use this crate for a long running pub sub. In some case, a lot of time (hours) can occurs between each messages.

In this exemple I send something every 60 secs. If the client closes the connection, I only have an error the next time the 60 secs timer fires and I would like to know right away if possible.

struct TestService;

impl TestCase for TestService {
    fn sub(&self, ctx: RpcContext, _req: Empty, sink: ServerStreamingSink<Notification>) {
        println!("new connection");

        let (tx, rx) = futures::sync::mpsc::unbounded();

        thread::spawn(move || loop {
            println!("send");
            tx.unbounded_send(1).unwrap();
            thread::sleep(time::Duration::from_secs(60));
        });

        let f = rx.map(|v| {
            let mut n = Notification::new();
            n.set_value(v.to_string());
            (n, WriteFlags::default())
        }).map_err(|()| err_msg("error rx"))
            .forward(sink)
            .map(|_| ())
            .map_err(|e| {
                println!("error: {}", e);
                ()
            });

        ctx.spawn(f);
    }
}

Bad codegen

I’m seeing bad codegen with protoc version 3.0.0 and latest rust grpc plugin.

Specifically proto grpc api generated passes the request by reference but unary_call requires it by value.

Similarly iter_opt method returns a result but codegen doesn’t wrap in Ok.

Consequently have to fix this by hand...

can you provide a greeter_async_client example?

In c++, i can send multiple async rpc request in a non-block way, and then in another thread, i will get rpc result through CompletionQueue.

how can i do this with your rust grpc.

Linking fails: /usr/lib/libssl.so.1.1: error adding symbols: DSO missing from command line

A clean project with:

[dependencies]
grpcio-proto = "0.2.0"
oauth2 = "1.3.0"

and main.rs:

extern crate oauth2;
fn main() {
  oauth2::Config::new("", "", "","").authorize_url();
}

Will fail linking with:

error: linking with cc failed: exit code: 1
|
= note: /usr/bin/ld: /home/user/git/project/target/debug/deps/libopenssl_sys-595a0ddae1d3fd8b.rlib(openssl_sys-595a0ddae1d3fd8b.openssl_sys2.rcgu.o): undefined reference to symbol 'SSL_ctrl@@OPENSSL_1_1_0'
/usr/lib/libssl.so.1.1: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status

I do have the libssl.so, it contains the symbol, and -l ssl appears on the linker line. I've also tried moving the -l's around but no change.

Oddly enough if I comment out either the "authorize_url" line or the grpcio-proto dep, it works. A grpcio dep with features = ["secure"] will also repro. I kind of suspect its not oauth2 since it doesn't have any linker-generated code like grpc-rs.

Any clue to solving this? The only similar issue I found was this one resulting from a bad link ordering. My gut tells me it might be somewhere around grpcio-sys/build.rs but I am just learning Rust and kind of at a dead end.

port go grpc tests

https://github.com/grpc/grpc-go/tree/master/test

general use or tikv only?

is there any readme or else? this is build for tikv only or a general grpc implimentation in rust?

Is there a interface to support diffie-hellman algorithm?

As the stream is not safe in grpc insecure channel, is there a interface that I can use diffie-hellman algorithm in transfer progress?

protobuf dependency is really outdated

Current protobuf dependency is 1.2 a year old, latest is 1.6.
Because of that:

cargo install grpcio-compiler 

Is failing, it's trying to download protobuf 1.6.

Add a basics tutorial to show how to use this crate

Although there are examples and tests already, it would be better to have a tutorial just like https://grpc.io/docs/ lists.

streaming call is not canceled when channel is dropped

We observe that in some case streaming call won't be canceled automatically when underlying channel is dropped. It can be reproduced reliably with TiKV, though a simple ping pong example can't reproduced it yet.

upgrade to use gRPC C core 1.7

Synchronous API?

Is there a way to use grpc-rs without futures, i.e. just synchronously? I ask because I'm dealing with !Sync types, and it's not clear to me whether it's possible to use them with grpcio::RpcContext::spawn.

Alarm is never fired

After upgrading to gRPC 1.7.2, alarm is not fired anymore, which lead to hang forever in threaded application.

performance / multi threading

It seems by default it runs on single thread, is there any way to use multiple threads?
I've tried to run it with:

let env = Arc::new(EnvBuilder::new().build());

And it still consumes only 1 core.

This doesn't work as well, still only 1 core is busy:

let env = Arc::new(Environment::new(8));

I'm creating just 1 grpc connection from the client. I expect server still should be able to use multiple cores.
Creating multiple connections also doesn't help, performance is still a lot worse than go's grpc server.

I'm sending 1M hello requests:
go: 22 seconds.
grpcio: 38 seconds.

port long tests from rust-grpc

https://github.com/stepancheg/grpc-rust/tree/master/long-tests

When targetting i686-pc-windows-msvc linker fails

When I create a binary targetting x86_64-pc-windows-msvc everything seems to work as expected. When I change to target i686-pc-windows-msvc I get a linking error:

error: linking with `link.exe` failed: exit code: 1120
  |
  = note: "C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\VC\\bin\\amd64_x86\\link.exe" "/NOLOGO" "/NXCOMPAT" "/LARGEADDRESSAWARE" "/SAFESEH" "/LIBPATH:C:\\Users\\Simon\\.rustup\\toolchains\\stable-i686-pc-windows-msvc\\lib\\rustlib\\i686-pc-windows-msvc\\lib" "C:\\code\\rust\\grpctestclient\\target\\debug\\deps\\grpctestclient-22dd802a760831fb.0.o" "/OUT:C:\\code\\rust\\grpctestclient\\target\\debug\\deps\\grpctestclient-22dd802a760831fb.exe" "C:\\code\\rust\\grpctestclient\\target\\debug\\deps\\grpctestclient-22dd802a760831fb.crate.allocator.o" "/OPT:REF,NOICF" "/DEBUG" "/LIBPATH:C:\\code\\rust\\grpctestclient\\target\\debug\\deps" "/LIBPATH:C:\\code\\rust\\grpctestclient\\target\\debug\\build\\grpcio-sys-8d76f4e474ce88cb\\out/build/Debug" "/LIBPATH:C:\\code\\rust\\grpctestclient\\target\\debug\\build\\grpcio-sys-8d76f4e474ce88cb\\out/build/third_party/cares/Debug" "/LIBPATH:C:\\code\\rust\\grpctestclient\\target\\debug\\build\\grpcio-sys-8d76f4e474ce88cb\\out/build/third_party/zlib/Debug" "/LIBPATH:C:\\code\\rust\\grpctestclient\\target\\debug\\build\\grpcio-sys-8d76f4e474ce88cb\\out/build/third_party/boringssl/ssl/Debug" "/LIBPATH:C:\\code\\rust\\grpctestclient\\target\\debug\\build\\grpcio-sys-8d76f4e474ce88cb\\out/build/third_party/boringssl/crypto/Debug" "/LIBPATH:C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\VC\\atlmfc\\lib\\" "/LIBPATH:C:\\code\\rust\\grpctestclient\\target\\debug\\build\\grpcio-sys-8d76f4e474ce88cb\\out" "/LIBPATH:C:\\Users\\Simon\\.rustup\\toolchains\\stable-i686-pc-windows-msvc\\lib\\rustlib\\i686-pc-windows-msvc\\lib" "C:\\Users\\Simon\\.rustup\\toolchains\\stable-i686-pc-windows-msvc\\lib\\rustlib\\i686-pc-windows-msvc\\lib\\libtest-4a2ffbd5d1de8748.rlib" "C:\\Users\\Simon\\.rustup\\toolchains\\stable-i686-pc-windows-msvc\\lib\\rustlib\\i686-pc-windows-msvc\\lib\\libgetopts-bb18395838510ee5.rlib" "C:\\code\\rust\\grpctestclient\\target\\debug\\deps\\libgrpcio-d135e1252312e2fe.rlib" "C:\\Users\\Simon\\.rustup\\toolchains\\stable-i686-pc-windows-msvc\\lib\\rustlib\\i686-pc-windows-msvc\\lib\\libterm-e82ad60c07d5ce89.rlib" "C:\\code\\rust\\grpctestclient\\target\\debug\\deps\\libtls_api_native_tls-4d98a338377eb70b.rlib" "C:\\code\\rust\\grpctestclient\\target\\debug\\deps\\libgrpcio_sys-c1500af703d76486.rlib" "C:\\code\\rust\\grpctestclient\\target\\debug\\deps\\libnative_tls-dd77dac0d4b4d2f9.rlib" "C:\\code\\rust\\grpctestclient\\target\\debug\\deps\\liblibc-c819602701b7e0ca.rlib" "C:\\code\\rust\\grpctestclient\\target\\debug\\deps\\libschannel-db045e030030947e.rlib" "C:\\code\\rust\\grpctestclient\\target\\debug\\deps\\liblazy_static-a8ae7b6260dfbfb6.rlib" "C:\\code\\rust\\grpctestclient\\target\\debug\\deps\\libadvapi32-c5f0c7faeb05dd68.rlib" "C:\\code\\rust\\grpctestclient\\target\\debug\\deps\\libprotobuf-8f6e9a787c870112.rlib" "C:\\code\\rust\\grpctestclient\\target\\debug\\deps\\libcrypt32-bfac4fca0bf3c582.rlib" "C:\\code\\rust\\grpctestclient\\target\\debug\\deps\\libhttpbis-5698fdf2a284a85d.rlib" "C:\\code\\rust\\grpctestclient\\target\\debug\\deps\\libtokio_tls_api-7005842da04e624b.rlib" "C:\\code\\rust\\grpctestclient\\target\\debug\\deps\\libtls_api_stub-baa0617cf4118d4c.rlib" "C:\\code\\rust\\grpctestclient\\target\\debug\\deps\\libvoid-e98405aa43567aa9.rlib" "C:\\code\\rust\\grpctestclient\\target\\debug\\deps\\libtokio_timer-1ca6361aeb5dea75.rlib" "C:\\code\\rust\\grpctestclient\\target\\debug\\deps\\libtokio_core-d6137ee4a21ff9d3.rlib" "C:\\code\\rust\\grpctestclient\\target\\debug\\deps\\libscoped_tls-0c128279b6f54e76.rlib" "C:\\code\\rust\\grpctestclient\\target\\debug\\deps\\libtokio_io-0a452ec1c3e89601.rlib" "C:\\code\\rust\\grpctestclient\\target\\debug\\deps\\libmio-af66d2fa429b98ee.rlib" "C:\\code\\rust\\grpctestclient\\target\\debug\\deps\\libmiow-efba840c83ef764a.rlib" "C:\\code\\rust\\grpctestclient\\target\\debug\\deps\\libslab-3682ad05451db221.rlib" "C:\\code\\rust\\grpctestclient\\target\\debug\\deps\\liblazycell-d93b41e1e6cfc529.rlib" "C:\\code\\rust\\grpctestclient\\target\\debug\\deps\\libbytes-a293a0e693d816bf.rlib" "C:\\code\\rust\\grpctestclient\\target\\debug\\deps\\libiovec-7342dacdd18faf24.rlib" "C:\\code\\rust\\grpctestclient\\target\\debug\\deps\\libbyteorder-9f659a19469e04e7.rlib" "C:\\code\\rust\\grpctestclient\\target\\debug\\deps\\liblog-cbb1b7356a5089ec.rlib" "C:\\code\\rust\\grpctestclient\\target\\debug\\deps\\libsecur32-0b426bc72f20236e.rlib" "C:\\code\\rust\\grpctestclient\\target\\debug\\deps\\libtls_api-05bc1aa0754fce7d.rlib" "C:\\code\\rust\\grpctestclient\\target\\debug\\deps\\libnet2-c2616e29d4ce9af8.rlib" "C:\\code\\rust\\grpctestclient\\target\\debug\\deps\\libcfg_if-342e0d390982db09.rlib" "C:\\code\\rust\\grpctestclient\\target\\debug\\deps\\libws2_32-8a8a075799b13f18.rlib" "C:\\code\\rust\\grpctestclient\\target\\debug\\deps\\libkernel32-c15f9a2439315d77.rlib" "C:\\code\\rust\\grpctestclient\\target\\debug\\deps\\libwinapi-8b24607fe36df8d1.rlib" "C:\\code\\rust\\grpctestclient\\target\\debug\\deps\\libfutures_cpupool-bb627e48a89392d4.rlib" "C:\\code\\rust\\grpctestclient\\target\\debug\\deps\\libnum_cpus-6f264736150b20e1.rlib" "C:\\code\\rust\\grpctestclient\\target\\debug\\deps\\libfutures-c07957cef9ac0120.rlib" "C:\\Users\\Simon\\.rustup\\toolchains\\stable-i686-pc-windows-msvc\\lib\\rustlib\\i686-pc-windows-msvc\\lib\\libstd-cb715f4af2c20b97.rlib" "C:\\Users\\Simon\\.rustup\\toolchains\\stable-i686-pc-windows-msvc\\lib\\rustlib\\i686-pc-windows-msvc\\lib\\libpanic_unwind-0fa8dbd47e2c76ee.rlib" "C:\\Users\\Simon\\.rustup\\toolchains\\stable-i686-pc-windows-msvc\\lib\\rustlib\\i686-pc-windows-msvc\\lib\\libunwind-c591e8b5c7fa4410.rlib" "C:\\Users\\Simon\\.rustup\\toolchains\\stable-i686-pc-windows-msvc\\lib\\rustlib\\i686-pc-windows-msvc\\lib\\liblibc-4a73c6ed200bc6a7.rlib" "C:\\Users\\Simon\\.rustup\\toolchains\\stable-i686-pc-windows-msvc\\lib\\rustlib\\i686-pc-windows-msvc\\lib\\liballoc_system-149ec0f4aeac373b.rlib" "C:\\Users\\Simon\\.rustup\\toolchains\\stable-i686-pc-windows-msvc\\lib\\rustlib\\i686-pc-windows-msvc\\lib\\liballoc-7ced75ab424a1846.rlib" "C:\\Users\\Simon\\.rustup\\toolchains\\stable-i686-pc-windows-msvc\\lib\\rustlib\\i686-pc-windows-msvc\\lib\\libstd_unicode-11a286598ffea675.rlib" "C:\\Users\\Simon\\.rustup\\toolchains\\stable-i686-pc-windows-msvc\\lib\\rustlib\\i686-pc-windows-msvc\\lib\\librand-093396b7aafa4528.rlib" "C:\\Users\\Simon\\.rustup\\toolchains\\stable-i686-pc-windows-msvc\\lib\\rustlib\\i686-pc-windows-msvc\\lib\\libcore-8b3b509fc1c5b3f9.rlib" "C:\\Users\\Simon\\.rustup\\toolchains\\stable-i686-pc-windows-msvc\\lib\\rustlib\\i686-pc-windows-msvc\\lib\\libcompiler_builtins-e9a8d8f9e3a2e5ce.rlib" "kernel32.lib" "ncrypt.lib" "advapi32.lib" "crypt32.lib" "secur32.lib" "ws2_32.lib" "kernel32.lib" "advapi32.lib" "ws2_32.lib" "userenv.lib" "shell32.lib" "msvcrt.lib"
  = note: grpctestclient-22dd802a760831fb.0.o : error LNK2019: unresolved external symbol _grpcwrap_call_start_duplex_streaming referenced in function __ZN6grpcio4call6client36_$LT$impl$u20$grpcio..call..Call$GT$16duplex_streaming28_$u7b$$u7b$closure$u7d$$u7d$17h1d7b3d1e0aec55cbE
          grpctestclient-22dd802a760831fb.0.o : error LNK2019: unresolved external symbol _grpcwrap_call_recv_initial_metadata referenced in function __ZN6grpcio4call6client36_$LT$impl$u20$grpcio..call..Call$GT$16duplex_streaming28_$u7b$$u7b$closure$u7d$$u7d$17ha4594e2bed7e0e93E
          grpctestclient-22dd802a760831fb.0.o : error LNK2019: unresolved external symbol _grpcwrap_channel_create_call referenced in function __ZN6grpcio7channel7Channel11create_call17h88b7521c5d488f9cE
          libgrpcio-d135e1252312e2fe.rlib(grpcio-d135e1252312e2fe.0.o) : error LNK2019: unresolved external symbol _grpcwrap_request_call_context_create referenced in function __ZN6grpcio4call6server14RequestContext3new17hcd767579623c2bbbE
          libgrpcio-d135e1252312e2fe.rlib(grpcio-d135e1252312e2fe.0.o) : error LNK2019: unresolved external symbol _grpcwrap_request_call_context_get_call referenced in function __ZN6grpcio4call6server14RequestContext16handle_unary_req17h9ed79af7c4e04ce1E
          libgrpcio-d135e1252312e2fe.rlib(grpcio-d135e1252312e2fe.0.o) : error LNK2019: unresolved external symbol _grpcwrap_call_recv_message referenced in function __ZN6grpcio4call6server14RequestContext16handle_unary_req17h9ed79af7c4e04ce1E
          libgrpcio-d135e1252312e2fe.rlib(grpcio-d135e1252312e2fe.0.o) : error LNK2019: unresolved external symbol _grpcwrap_request_call_context_take_call referenced in function __ZN6grpcio4call6server14RequestContext9take_call17h950537a2864000a3E
          libgrpcio-d135e1252312e2fe.rlib(grpcio-d135e1252312e2fe.0.o) : error LNK2019: unresolved external symbol _grpcwrap_request_call_context_method referenced in function __ZN6grpcio4call6server14RequestContext6method17h61867e52d772dc37E
          libgrpcio-d135e1252312e2fe.rlib(grpcio-d135e1252312e2fe.0.o) : error LNK2019: unresolved external symbol _grpcwrap_request_call_context_host referenced in function __ZN6grpcio4call6server14RequestContext4host17h36740be0b259d3d1E
          libgrpcio-d135e1252312e2fe.rlib(grpcio-d135e1252312e2fe.0.o) : error LNK2019: unresolved external symbol _grpcwrap_request_call_context_deadline referenced in function __ZN6grpcio4call6server14RequestContext8deadline17ha4e6407b18c20ac4E
          libgrpcio-d135e1252312e2fe.rlib(grpcio-d135e1252312e2fe.0.o) : error LNK2019: unresolved external symbol _grpcwrap_request_call_context_destroy referenced in function __ZN78_$LT$grpcio..call..server..RequestContext$u20$as$u20$core..ops..drop..Drop$GT$4drop17h6903b934e12ca739E
          libgrpcio-d135e1252312e2fe.rlib(grpcio-d135e1252312e2fe.0.o) : error LNK2019: unresolved external symbol _grpcwrap_batch_context_create referenced in function __ZN6grpcio4call12BatchContext3new17h313eb149fc0232d6E
          libgrpcio-d135e1252312e2fe.rlib(grpcio-d135e1252312e2fe.0.o) : error LNK2019: unresolved external symbol _grpcwrap_batch_context_recv_status_on_client_status referenced in function __ZN6grpcio4call12BatchContext10rpc_status17h19bf73b538dd97b6E
          libgrpcio-d135e1252312e2fe.rlib(grpcio-d135e1252312e2fe.0.o) : error LNK2019: unresolved external symbol _grpcwrap_batch_context_recv_status_on_client_details referenced in function __ZN6grpcio4call12BatchContext10rpc_status17h19bf73b538dd97b6E
          libgrpcio-d135e1252312e2fe.rlib(grpcio-d135e1252312e2fe.0.o) : error LNK2019: unresolved external symbol _grpcwrap_batch_context_recv_message_length referenced in function __ZN6grpcio4call12BatchContext12recv_message17hecad8a06d1154dc1E
          libgrpcio-d135e1252312e2fe.rlib(grpcio-d135e1252312e2fe.0.o) : error LNK2019: unresolved external symbol _grpcwrap_batch_context_recv_message_to_buffer referenced in function __ZN6grpcio4call12BatchContext12recv_message17hecad8a06d1154dc1E
          libgrpcio-d135e1252312e2fe.rlib(grpcio-d135e1252312e2fe.0.o) : error LNK2019: unresolved external symbol _grpcwrap_batch_context_destroy referenced in function __ZN68_$LT$grpcio..call..BatchContext$u20$as$u20$core..ops..drop..Drop$GT$4drop17h03cbf64e3116f2d2E
          libgrpcio-d135e1252312e2fe.rlib(grpcio-d135e1252312e2fe.0.o) : error LNK2019: unresolved external symbol _grpcwrap_call_send_message referenced in function __ZN6grpcio4call4Call18start_send_message28_$u7b$$u7b$closure$u7d$$u7d$17h10144ea50e6d50ebE
          libgrpcio-d135e1252312e2fe.rlib(grpcio-d135e1252312e2fe.0.o) : error LNK2019: unresolved external symbol _grpcwrap_call_send_close_from_client referenced in function __ZN6grpcio4call4Call23start_send_close_client28_$u7b$$u7b$closure$u7d$$u7d$17h1d578467004b386cE
          libgrpcio-d135e1252312e2fe.rlib(grpcio-d135e1252312e2fe.0.o) : error LNK2019: unresolved external symbol _grpcwrap_call_start_serverside referenced in function __ZN6grpcio4call4Call17start_server_side28_$u7b$$u7b$closure$u7d$$u7d$17h8d7af00415d0a313E
          libgrpcio-d135e1252312e2fe.rlib(grpcio-d135e1252312e2fe.0.o) : error LNK2019: unresolved external symbol _grpcwrap_call_send_status_from_server referenced in function __ZN6grpcio4call4Call29start_send_status_from_server28_$u7b$$u7b$closure$u7d$$u7d$17h36ba0ae05577b75dE
          libgrpcio-d135e1252312e2fe.rlib(grpcio-d135e1252312e2fe.0.o) : error LNK2019: unresolved external symbol _grpcwrap_channel_args_create referenced in function __ZN6grpcio7channel14ChannelBuilder10build_args17h205b65bf5e901e37E
          libgrpcio-d135e1252312e2fe.rlib(grpcio-d135e1252312e2fe.0.o) : error LNK2019: unresolved external symbol _grpcwrap_channel_args_set_integer referenced in function __ZN6grpcio7channel14ChannelBuilder10build_args17h205b65bf5e901e37E
          libgrpcio-d135e1252312e2fe.rlib(grpcio-d135e1252312e2fe.0.o) : error LNK2019: unresolved external symbol _grpcwrap_channel_args_set_string referenced in function __ZN6grpcio7channel14ChannelBuilder10build_args17h205b65bf5e901e37E
          libgrpcio-d135e1252312e2fe.rlib(grpcio-d135e1252312e2fe.0.o) : error LNK2019: unresolved external symbol _grpcwrap_channel_args_destroy referenced in function __ZN70_$LT$grpcio..channel..ChannelArgs$u20$as$u20$core..ops..drop..Drop$GT$4drop17h6414f3e9806d0052E
          libgrpcio-d135e1252312e2fe.rlib(grpcio-d135e1252312e2fe.0.o) : error LNK2019: unresolved external symbol _grpcwrap_ssl_server_credentials_create referenced in function __ZN6grpcio11credentials24ServerCredentialsBuilder5build17h9d376d731225cac4E
          libgrpcio-d135e1252312e2fe.rlib(grpcio-d135e1252312e2fe.0.o) : error LNK2019: unresolved external symbol _grpcwrap_ssl_credentials_create referenced in function __ZN6grpcio11credentials25ChannelCredentialsBuilder5build17h120f4d402cfaa98fE
          libgrpcio-d135e1252312e2fe.rlib(grpcio-d135e1252312e2fe.0.o) : error LNK2019: unresolved external symbol _grpcwrap_server_request_call referenced in function __ZN6grpcio6server12request_call17h15fec5bc04c4d623E
          C:\code\rust\grpctestclient\target\debug\deps\grpctestclient-22dd802a760831fb.exe : fatal error LNK1120: 28 unresolved externals


error: aborting due to previous error

A similiar thing happens when running cargo test on grpc-rc targetting i686-pc-windows-msvc (again x86_64-pc-windows-msvc works as expected):

error: linking with `link.exe` failed: exit code: 1120
  |
  = note: "C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\VC\\bin\\amd64_x86\\link.exe" "/NOLOGO" "/NXCOMPAT" "/LARGEADDRESSAWARE" "/SAFESEH" "/LIBPATH:C:\\Users\\Simon\\.rustup\\toolchains\\stable-i686-pc-windows-msvc\\lib\\rustlib\\i686-pc-windows-msvc\\lib" "C:\\code\\rust\\grpc-rs\\target\\debug\\examples\\greeter_server-5b7ff584f698d1c3.0.o" "/OUT:C:\\code\\rust\\grpc-rs\\target\\debug\\examples\\greeter_server-5b7ff584f698d1c3.exe" "C:\\code\\rust\\grpc-rs\\target\\debug\\examples\\greeter_server-5b7ff584f698d1c3.crate.allocator.o" "/OPT:REF,NOICF" "/DEBUG" "/LIBPATH:C:\\code\\rust\\grpc-rs\\target\\debug\\deps" "/LIBPATH:C:\\code\\rust\\grpc-rs\\target\\debug\\build\\grpcio-sys-ad7ef0ad3da8d23a\\out/build/Debug" "/LIBPATH:C:\\code\\rust\\grpc-rs\\target\\debug\\build\\grpcio-sys-ad7ef0ad3da8d23a\\out/build/third_party/cares/Debug" "/LIBPATH:C:\\code\\rust\\grpc-rs\\target\\debug\\build\\grpcio-sys-ad7ef0ad3da8d23a\\out/build/third_party/zlib/Debug" "/LIBPATH:C:\\code\\rust\\grpc-rs\\target\\debug\\build\\grpcio-sys-ad7ef0ad3da8d23a\\out/build/third_party/boringssl/ssl/Debug" "/LIBPATH:C:\\code\\rust\\grpc-rs\\target\\debug\\build\\grpcio-sys-ad7ef0ad3da8d23a\\out/build/third_party/boringssl/crypto/Debug" "/LIBPATH:C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\VC\\atlmfc\\lib\\" "/LIBPATH:C:\\code\\rust\\grpc-rs\\target\\debug\\build\\grpcio-sys-ad7ef0ad3da8d23a\\out" "/LIBPATH:C:\\Users\\Simon\\.rustup\\toolchains\\stable-i686-pc-windows-msvc\\lib\\rustlib\\i686-pc-windows-msvc\\lib" "C:\\code\\rust\\grpc-rs\\target\\debug\\deps\\libgrpcio_proto-f81184248277bc6e.rlib" "C:\\code\\rust\\grpc-rs\\target\\debug\\deps\\libslog_term-68b5471fa7f08fbf.rlib" "C:\\code\\rust\\grpc-rs\\target\\debug\\deps\\libterm-f854bf64fae3c501.rlib" "C:\\code\\rust\\grpc-rs\\target\\debug\\deps\\libisatty-e3e6fe9705e46736.rlib" "C:\\code\\rust\\grpc-rs\\target\\debug\\deps\\libchrono-62d9840c3b21e416.rlib" "C:\\code\\rust\\grpc-rs\\target\\debug\\deps\\libnum-c0ce31775841def5.rlib" "C:\\code\\rust\\grpc-rs\\target\\debug\\deps\\libtime-8fc3a3e9a37310e2.rlib" "C:\\code\\rust\\grpc-rs\\target\\debug\\deps\\libkernel32-c15f9a2439315d77.rlib" "C:\\code\\rust\\grpc-rs\\target\\debug\\deps\\libwinapi-8b24607fe36df8d1.rlib" "C:\\code\\rust\\grpc-rs\\target\\debug\\deps\\libslog_stdlog-7a53680d894706bd.rlib" "C:\\code\\rust\\grpc-rs\\target\\debug\\deps\\libslog_scope-7d3a96d7a1425a26.rlib" "C:\\code\\rust\\grpc-rs\\target\\debug\\deps\\libslog_async-7c99da4eb6b7296b.rlib" "C:\\code\\rust\\grpc-rs\\target\\debug\\deps\\libtake_mut-2ecaf07df722bece.rlib" "C:\\code\\rust\\grpc-rs\\target\\debug\\deps\\libthread_local-9ccb72a75948b8ef.rlib" "C:\\code\\rust\\grpc-rs\\target\\debug\\deps\\liblazy_static-06b18921fa9d687f.rlib" "C:\\code\\rust\\grpc-rs\\target\\debug\\deps\\libunreachable-3ebc2be93b299b04.rlib" "C:\\code\\rust\\grpc-rs\\target\\debug\\deps\\libvoid-758ade381656fe45.rlib" "C:\\code\\rust\\grpc-rs\\target\\debug\\deps\\libgrpcio-5e40bbfcffa50f6a.rlib" "C:\\code\\rust\\grpc-rs\\target\\debug\\deps\\libprotobuf-8f6e9a787c870112.rlib" "C:\\code\\rust\\grpc-rs\\target\\debug\\deps\\liblog-cbb1b7356a5089ec.rlib" "C:\\code\\rust\\grpc-rs\\target\\debug\\deps\\libgrpcio_sys-2989227e05ced6b1.rlib" "C:\\code\\rust\\grpc-rs\\target\\debug\\deps\\liblibc-c819602701b7e0ca.rlib" "C:\\code\\rust\\grpc-rs\\target\\debug\\deps\\libfutures-c07957cef9ac0120.rlib" "C:\\code\\rust\\grpc-rs\\target\\debug\\deps\\libnum_iter-83c1e49d83d2a8e7.rlib" "C:\\code\\rust\\grpc-rs\\target\\debug\\deps\\libnum_integer-12644b41e0d481e7.rlib" "C:\\code\\rust\\grpc-rs\\target\\debug\\deps\\libnum_traits-89eaeeb6951b2c47.rlib" "C:\\code\\rust\\grpc-rs\\target\\debug\\deps\\libcrossbeam-b8befa5a22f932f8.rlib" "C:\\code\\rust\\grpc-rs\\target\\debug\\deps\\libslog-1420a44cbad7e71e.rlib" "C:\\Users\\Simon\\.rustup\\toolchains\\stable-i686-pc-windows-msvc\\lib\\rustlib\\i686-pc-windows-msvc\\lib\\libstd-cb715f4af2c20b97.rlib" "C:\\Users\\Simon\\.rustup\\toolchains\\stable-i686-pc-windows-msvc\\lib\\rustlib\\i686-pc-windows-msvc\\lib\\libpanic_unwind-0fa8dbd47e2c76ee.rlib" "C:\\Users\\Simon\\.rustup\\toolchains\\stable-i686-pc-windows-msvc\\lib\\rustlib\\i686-pc-windows-msvc\\lib\\libunwind-c591e8b5c7fa4410.rlib" "C:\\Users\\Simon\\.rustup\\toolchains\\stable-i686-pc-windows-msvc\\lib\\rustlib\\i686-pc-windows-msvc\\lib\\liblibc-4a73c6ed200bc6a7.rlib" "C:\\Users\\Simon\\.rustup\\toolchains\\stable-i686-pc-windows-msvc\\lib\\rustlib\\i686-pc-windows-msvc\\lib\\liballoc_system-149ec0f4aeac373b.rlib" "C:\\Users\\Simon\\.rustup\\toolchains\\stable-i686-pc-windows-msvc\\lib\\rustlib\\i686-pc-windows-msvc\\lib\\liballoc-7ced75ab424a1846.rlib" "C:\\Users\\Simon\\.rustup\\toolchains\\stable-i686-pc-windows-msvc\\lib\\rustlib\\i686-pc-windows-msvc\\lib\\libstd_unicode-11a286598ffea675.rlib" "C:\\Users\\Simon\\.rustup\\toolchains\\stable-i686-pc-windows-msvc\\lib\\rustlib\\i686-pc-windows-msvc\\lib\\librand-093396b7aafa4528.rlib" "C:\\Users\\Simon\\.rustup\\toolchains\\stable-i686-pc-windows-msvc\\lib\\rustlib\\i686-pc-windows-msvc\\lib\\libcore-8b3b509fc1c5b3f9.rlib" "C:\\Users\\Simon\\.rustup\\toolchains\\stable-i686-pc-windows-msvc\\lib\\rustlib\\i686-pc-windows-msvc\\lib\\libcompiler_builtins-e9a8d8f9e3a2e5ce.rlib" "kernel32.lib" "advapi32.lib" "ws2_32.lib" "userenv.lib" "shell32.lib" "msvcrt.lib"
  = note: libgrpcio_proto-f81184248277bc6e.rlib(grpcio_proto-f81184248277bc6e.0.o) : error LNK2019: unresolved external symbol _grpcwrap_call_start_unary referenced in function __ZN6grpcio4call6client36_$LT$impl$u20$grpcio..call..Call$GT$11unary_async28_$u7b$$u7b$closure$u7d$$u7d$17h03917d3e6fab05b3E
          libgrpcio_proto-f81184248277bc6e.rlib(grpcio_proto-f81184248277bc6e.0.o) : error LNK2019: unresolved external symbol _grpcwrap_call_start_client_streaming referenced in function __ZN6grpcio4call6client36_$LT$impl$u20$grpcio..call..Call$GT$16client_streaming28_$u7b$$u7b$closure$u7d$$u7d$17h10541628a09acfaeE
          libgrpcio_proto-f81184248277bc6e.rlib(grpcio_proto-f81184248277bc6e.0.o) : error LNK2019: unresolved external symbol _grpcwrap_call_start_duplex_streaming referenced in function __ZN6grpcio4call6client36_$LT$impl$u20$grpcio..call..Call$GT$16duplex_streaming28_$u7b$$u7b$closure$u7d$$u7d$17h0864579e6e590fc2E
          libgrpcio_proto-f81184248277bc6e.rlib(grpcio_proto-f81184248277bc6e.0.o) : error LNK2019: unresolved external symbol _grpcwrap_call_recv_initial_metadata referenced in function __ZN6grpcio4call6client36_$LT$impl$u20$grpcio..call..Call$GT$16duplex_streaming28_$u7b$$u7b$closure$u7d$$u7d$17h149b9bea1d749922E
          libgrpcio_proto-f81184248277bc6e.rlib(grpcio_proto-f81184248277bc6e.0.o) : error LNK2019: unresolved external symbol _grpcwrap_call_start_server_streaming referenced in function __ZN6grpcio4call6client36_$LT$impl$u20$grpcio..call..Call$GT$16server_streaming28_$u7b$$u7b$closure$u7d$$u7d$17h7940bf8c2089c134E
          libgrpcio_proto-f81184248277bc6e.rlib(grpcio_proto-f81184248277bc6e.0.o) : error LNK2019: unresolved external symbol _grpcwrap_channel_create_call referenced in function __ZN6grpcio7channel7Channel11create_call17h039d52431350efe7E
          libgrpcio-5e40bbfcffa50f6a.rlib(grpcio-5e40bbfcffa50f6a.0.o) : error LNK2019: unresolved external symbol _grpcwrap_request_call_context_create referenced in function __ZN6grpcio4call6server14RequestContext3new17hd12bf3663bccef6dE
          libgrpcio-5e40bbfcffa50f6a.rlib(grpcio-5e40bbfcffa50f6a.0.o) : error LNK2019: unresolved external symbol _grpcwrap_request_call_context_get_call referenced in function __ZN6grpcio4call6server14RequestContext16handle_unary_req17hc07924e60a276058E
          libgrpcio-5e40bbfcffa50f6a.rlib(grpcio-5e40bbfcffa50f6a.0.o) : error LNK2019: unresolved external symbol _grpcwrap_call_recv_message referenced in function __ZN6grpcio4call6server14RequestContext16handle_unary_req17hc07924e60a276058E
          libgrpcio-5e40bbfcffa50f6a.rlib(grpcio-5e40bbfcffa50f6a.0.o) : error LNK2019: unresolved external symbol _grpcwrap_request_call_context_take_call referenced in function __ZN6grpcio4call6server14RequestContext9take_call17h8fdb087fb6eee43eE
          libgrpcio-5e40bbfcffa50f6a.rlib(grpcio-5e40bbfcffa50f6a.0.o) : error LNK2019: unresolved external symbol _grpcwrap_request_call_context_method referenced in function __ZN6grpcio4call6server14RequestContext6method17hc8ef6f202af44022E
          libgrpcio-5e40bbfcffa50f6a.rlib(grpcio-5e40bbfcffa50f6a.0.o) : error LNK2019: unresolved external symbol _grpcwrap_request_call_context_host referenced in function __ZN6grpcio4call6server14RequestContext4host17h7383bd1de4aa4299E
          libgrpcio-5e40bbfcffa50f6a.rlib(grpcio-5e40bbfcffa50f6a.0.o) : error LNK2019: unresolved external symbol _grpcwrap_request_call_context_deadline referenced in function __ZN6grpcio4call6server14RequestContext8deadline17hf0949643c3dd3c85E
          libgrpcio-5e40bbfcffa50f6a.rlib(grpcio-5e40bbfcffa50f6a.0.o) : error LNK2019: unresolved external symbol _grpcwrap_request_call_context_destroy referenced in function __ZN78_$LT$grpcio..call..server..RequestContext$u20$as$u20$core..ops..drop..Drop$GT$4drop17hedee1af8d4b5d909E
          libgrpcio-5e40bbfcffa50f6a.rlib(grpcio-5e40bbfcffa50f6a.0.o) : error LNK2019: unresolved external symbol _grpcwrap_batch_context_create referenced in function __ZN6grpcio4call12BatchContext3new17h18bcd2e1798a9423E
          libgrpcio-5e40bbfcffa50f6a.rlib(grpcio-5e40bbfcffa50f6a.0.o) : error LNK2019: unresolved external symbol _grpcwrap_batch_context_recv_status_on_client_status referenced in function __ZN6grpcio4call12BatchContext10rpc_status17h924a64a7789c5d69E
          libgrpcio-5e40bbfcffa50f6a.rlib(grpcio-5e40bbfcffa50f6a.0.o) : error LNK2019: unresolved external symbol _grpcwrap_batch_context_recv_status_on_client_details referenced in function __ZN6grpcio4call12BatchContext10rpc_status17h924a64a7789c5d69E
          libgrpcio-5e40bbfcffa50f6a.rlib(grpcio-5e40bbfcffa50f6a.0.o) : error LNK2019: unresolved external symbol _grpcwrap_batch_context_recv_message_length referenced in function __ZN6grpcio4call12BatchContext12recv_message17h665a114a792cf18cE
          libgrpcio-5e40bbfcffa50f6a.rlib(grpcio-5e40bbfcffa50f6a.0.o) : error LNK2019: unresolved external symbol _grpcwrap_batch_context_recv_message_to_buffer referenced in function __ZN6grpcio4call12BatchContext12recv_message17h665a114a792cf18cE
          libgrpcio-5e40bbfcffa50f6a.rlib(grpcio-5e40bbfcffa50f6a.0.o) : error LNK2019: unresolved external symbol _grpcwrap_batch_context_destroy referenced in function __ZN68_$LT$grpcio..call..BatchContext$u20$as$u20$core..ops..drop..Drop$GT$4drop17haa599fad5b97746cE
          libgrpcio-5e40bbfcffa50f6a.rlib(grpcio-5e40bbfcffa50f6a.0.o) : error LNK2019: unresolved external symbol _grpcwrap_call_send_message referenced in function __ZN6grpcio4call4Call18start_send_message28_$u7b$$u7b$closure$u7d$$u7d$17h3dcef4688cbaa526E
          libgrpcio-5e40bbfcffa50f6a.rlib(grpcio-5e40bbfcffa50f6a.0.o) : error LNK2019: unresolved external symbol _grpcwrap_call_send_close_from_client referenced in function __ZN6grpcio4call4Call23start_send_close_client28_$u7b$$u7b$closure$u7d$$u7d$17h0d979c57620bdf95E
          libgrpcio-5e40bbfcffa50f6a.rlib(grpcio-5e40bbfcffa50f6a.0.o) : error LNK2019: unresolved external symbol _grpcwrap_call_start_serverside referenced in function __ZN6grpcio4call4Call17start_server_side28_$u7b$$u7b$closure$u7d$$u7d$17h3f816abf173a115aE
          libgrpcio-5e40bbfcffa50f6a.rlib(grpcio-5e40bbfcffa50f6a.0.o) : error LNK2019: unresolved external symbol _grpcwrap_call_send_status_from_server referenced in function __ZN6grpcio4call4Call29start_send_status_from_server28_$u7b$$u7b$closure$u7d$$u7d$17hcfb54c8319a74d4eE
          libgrpcio-5e40bbfcffa50f6a.rlib(grpcio-5e40bbfcffa50f6a.0.o) : error LNK2019: unresolved external symbol _grpcwrap_channel_args_create referenced in function __ZN6grpcio7channel14ChannelBuilder10build_args17hb2cb25756f4e6b53E
          libgrpcio-5e40bbfcffa50f6a.rlib(grpcio-5e40bbfcffa50f6a.0.o) : error LNK2019: unresolved external symbol _grpcwrap_channel_args_set_integer referenced in function __ZN6grpcio7channel14ChannelBuilder10build_args17hb2cb25756f4e6b53E
          libgrpcio-5e40bbfcffa50f6a.rlib(grpcio-5e40bbfcffa50f6a.0.o) : error LNK2019: unresolved external symbol _grpcwrap_channel_args_set_string referenced in function __ZN6grpcio7channel14ChannelBuilder10build_args17hb2cb25756f4e6b53E
          libgrpcio-5e40bbfcffa50f6a.rlib(grpcio-5e40bbfcffa50f6a.0.o) : error LNK2019: unresolved external symbol _grpcwrap_channel_args_destroy referenced in function __ZN70_$LT$grpcio..channel..ChannelArgs$u20$as$u20$core..ops..drop..Drop$GT$4drop17hbe7b031a31eae858E
          libgrpcio-5e40bbfcffa50f6a.rlib(grpcio-5e40bbfcffa50f6a.0.o) : error LNK2019: unresolved external symbol _grpcwrap_ssl_server_credentials_create referenced in function __ZN6grpcio11credentials24ServerCredentialsBuilder5build17hdbd9f7d5cf0ce426E
          libgrpcio-5e40bbfcffa50f6a.rlib(grpcio-5e40bbfcffa50f6a.0.o) : error LNK2019: unresolved external symbol _grpcwrap_ssl_credentials_create referenced in function __ZN6grpcio11credentials25ChannelCredentialsBuilder5build17haf98991752a8c69bE
          libgrpcio-5e40bbfcffa50f6a.rlib(grpcio-5e40bbfcffa50f6a.0.o) : error LNK2019: unresolved external symbol _grpcwrap_server_request_call referenced in function __ZN6grpcio6server12request_call17h1ccc10e8a779bbeeE
          C:\code\rust\grpc-rs\target\debug\examples\greeter_server-5b7ff584f698d1c3.exe : fatal error LNK1120: 31 unresolved externals


error: aborting due to previous error

error: Could not compile `grpcio`.

I tried running cargo test of grpc-rc on a clean Windows 10 32bit VM too to see if that would fix it, but I get the same error as above.

pass thread name when creating Environment

TiKV may use two different Environments, one for server and the other for PD, we should use a different name to distinguish these threads.

Update grpc's boringssl dep

I have a PR (grpc/grpc#13105) to grpc which updates boringssl to pick up several compile fixes for assorted older compilers that my project supports.

I'm not sure which branch I should be PRing against to get these merged into pingcap's fork of grpc. It looks like rs-release is where development is happening, but the branch currently isn't compatible with the rust code. And it looks like master is pretty out of date.

Can you give me a tip for where I should be PRing this to try to get it included in the next grpc-rs release?

Thanks,

wedge with ServerStreamingSink::wait()

I don't know if this is a bug or if I'm misunderstanding the usage.

I modified the route_guide example to show the problem:

diff --git a/examples/route_guide/server.rs b/examples/route_guide/server.rs
index 69b2475..4d73237 100644
--- a/examples/route_guide/server.rs
+++ b/examples/route_guide/server.rs
@@ -60,24 +60,25 @@ impl RouteGuide for RouteGuideService {

     fn list_features(&self, ctx: RpcContext, rect: Rectangle, resp: ServerStreamingSink<Feature>) {
         let data = self.data.clone();
         let features: Vec<_> = data.iter()
             .filter_map(move |f| if fit_in(f.get_location(), &rect) {
                 Some((f.to_owned(), WriteFlags::default()))
             } else {
                 None
             })
             .collect();
-        let f = resp.send_all(stream::iter_ok::<_, Error>(features))
-            .map(|_| {})
-            .map_err(|e| error!("failed to handle listfeatures request: {:?}", e));
-        ctx.spawn(f)
+        let mut wait = resp.wait();
+        for feature in features {
+            wait.send(feature).unwrap();
+        }
+        wait.close().unwrap();
     }

     fn record_route(
         &self,
         ctx: RpcContext,
         points: RequestStream<Point>,
         resp: ClientStreamingSink<RouteSummary>,
     ) {
         let data = self.data.clone();
         let timer = Instant::now();

I expected the above to successfully send the features vector to the client. Instead, the client receives the first feature, but then it receives no more features. The server seems to be stuck.

Is this a bug with wait()?

Sharing Environment in Arc deadlocks

Because I seem to create environment quite a lot, I thought I could simply reuse in a server making frequent connections and so wrapped it in an arc.

It compiles without warning.

However this seems to lead to deadlocks in the c grpcio threads; perhaps a warning would be good ?

support static link c gRPC library.

Like rust-rocksdb, we support linking c gRPC statically.

Support Reflection

Supporting reflection would allow service developers to test and experiment using tools like grpcurl. Other SDKs contain the the ability to register the reflection service ... is there a timeline for this or is anyone actively working on it?

Tests and benchmarks failed after upgrade gRPC to 1.7.2

As described in #113 (comment), benchmarks failed.
And unit tests fail frequently because of call.c:2032] assertion failed: grpc_cq_begin_op(call->cq, notify_tag)

For the benchmark, it looks like client and server failed to send the last message and close the connection, detailed logs:

Client:

Nov 18 14:34:27.584 INFO listening on [::]:10110
Nov 18 14:34:27.703 INFO receive client setup: server_targets: "localhost:33821" client_type: ASYNC_CLIENT security_params {use_test_ca: true server_host_override: "foo.test.google.fr"} outstanding_rpcs_per_channel: 100 client_channels: 64 rpc_type: STREAMING load_params {closed_loop {}} payload_config {simple_params {}} histogram_params {resolution: 0.01 max_possible: 60000000000} channel_args {name: "grpc.optimization_target" str_value: "throughput"}
Nov 18 14:34:27.859 INFO receive client mark: reset: true
Nov 18 14:34:32.864 INFO receive client mark: reset: true
Nov 18 14:35:02.862 INFO receive client mark: reset: true

Server:

Nov 18 14:34:27.581 INFO listening on [::]:10100
Nov 18 14:34:27.594 INFO receive server setup: server_type: ASYNC_SERVER security_params {use_test_ca: true server_host_override: "foo.test.google.fr"} channel_args {name: "grpc.optimization_target" str_value: "throughput"}
Nov 18 14:34:32.865 INFO receive server mark: reset: true

They are both missing a log for shutting down.
https://github.com/pingcap/grpc-rs/blob/e45a84332e7e8c5e490ade91a501610f612fdce8/benchmark/src/worker.rs#L113
https://github.com/pingcap/grpc-rs/blob/e45a84332e7e8c5e490ade91a501610f612fdce8/benchmark/src/worker.rs#L77

CC #107

add some tests for channel options.

Suggested by @siddontang at #137.

cargo build with openssl and grpcio will report error: undefined reference to `OPENSSL_add_all_algorithms_noconf'

My Cargo.toml as below:

[dependencies]
openssl = "0.9.20"
grpcio = "0.1"

run cargo build will report error:

note: /home/test/target/debug/deps/libopenssl_sys-83f37b3f53691d0c.rlib(openssl_sys-83f37b3f53691d0c.0.o): In function `openssl_sys::ossl10x::init::{{closure}}':
          /home/test/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-sys-0.9.20/src/o  l10x.rs:768: undefined reference to `OPENSSL_add_all_algorithms_noconf'
▽         collect2: error: ld returned 1 exit status

if I remove grpcio from Cargo.toml dependencies then cargo build will be ok. Anybody meet this case?

Can this be made to work with prost somehow?

rust-protobuf gives me headaches with our complex repo with many protos all over the place. However, since I require gRPC, I am using it still instead of prost which seems easier to work with.

Can this repo be made to work with prost somehow?

Codegen ergonomics: message construction

I do a lot of:

// get internal struct from somewhere
let mystruct = GetMyStruct::get();
let mut req = Req::new();
// now convert that struct anually to the request
req.set_foo(mystruct.foo);
req.set_bar(mystruct.bar);

This becomes very tedious, so I have a couple of suggestions:

Constructor with field params

it would be nice if I could have a constructor method like:

let req = Req::with(mystruct.foo, mystruct.bar);

and pass in the message fields as params.

Generic Conversion Trait

Similarly, it would be really great if codegen spit out something like:

trait ConvertInto<T> {
  fn convert_into(t: Self) -> T;
}

impl From<T: ConvertInto<Req>> for Req {
  fn from(t: T) -> Self {
     T::convert_into(t)
  }
}

Or something like that; I think you get the idea.

This way in my crate/upstream clients only have to impl ConvertInto<Req> for their internal datatypes, and can get conversion encapsulated in a single space (and protects refactoring somewhat by shielding struct changes, etc.) by essentially doing:

impl ConvertInto<Req> for Mystruct {
  fn convert_into(t: Mystruct) -> Req {
    let mut req = Req::new();
    req.foo = mystruct.foo;
    req.bar = mystruct.bar;
    req
  }
}
...
// which yields this nice code:
let req = GetMystruct::get().into();

Move `pb_codec` from the core library to compiler

Different codec usually has different compiler. So move it to compiler can make core library codec-independent by default, which is easy for supporting a new codec.

some unexpected pending gRPC thread

hread 3 (Thread 0x7f28b17fd700 (LWP 27399)):
#0  0x00007f2a8489b945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x000055594456b542 in gpr_cv_wait ()
#2  0x0000555944571877 in executor_thread ()
#3  0x00005559445924e7 in thread_body ()
#4  0x00007f2a84897e25 in start_thread () from /lib64/libpthread.so.0
#5  0x00007f2a843af34d in clone () from /lib64/libc.so.6
Thread 2 (Thread 0x7f28b0dfc700 (LWP 27400)):
#0  0x00007f2a8489b945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x000055594456b542 in gpr_cv_wait ()
#2  0x0000555944571877 in executor_thread ()
#3  0x00005559445924e7 in thread_body ()
#4  0x00007f2a84897e25 in start_thread () from /lib64/libpthread.so.0
#5  0x00007f2a843af34d in clone () from /lib64/libc.so.6

In our test, we find that some gRPC are waiting but do nothing, and we don't do any test now, the load is low, I think there may be something wrong.

Call `send` + `close` on `StreamingCallSink` will panic

Here is a simple test for learning grpc. We can use cargo run --bin server to run the server side, and cargo run --bin client to run the client side.

The client side will panic. Here is a code fragment:

    for i in 0..4 {
        let mut req = req.clone();
        req.set_message(format!("msg_{}", i));
        match sender.send((req, WriteFlags::default())).wait() {
            Ok(s) => sender = s,
            Err(e) => {
                println!("sender.send: {}", e);
                process::exit(0);
            }
        }
    }
    if let Err(e) = sender.close() {    // panic will happend here.
        println!("sender.close: {}", e);
        process::exit(0);
    }

panic stack backtrace:

thread 'main' panicked at 'no Task is currently running', /home/qupeng/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-0.1.16/src/task_impl/mod.rs:44:8
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
             at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at /checkout/src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at /checkout/src/libstd/sys_common/backtrace.rs:60
             at /checkout/src/libstd/panicking.rs:381
   3: std::panicking::default_hook
             at /checkout/src/libstd/panicking.rs:397
   4: std::panicking::rust_panic_with_hook
             at /checkout/src/libstd/panicking.rs:611
   5: std::panicking::begin_panic
             at /checkout/src/libstd/panicking.rs:572
   6: futures::task_impl::with
             at /home/qupeng/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-0.1.16/src/task_impl/mod.rs:44
   7: futures::task_impl::current
             at /home/qupeng/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-0.1.16/src/task_impl/mod.rs:90
   8: <grpcio::async::CqFuture<T> as futures::future::Future>::poll
             at /home/qupeng/.cargo/registry/src/github.com-1ecc6299db9ec823/grpcio-0.1.0/src/async/mod.rs:113
   9: <grpcio::call::client::StreamingCallSink<P> as futures::sink::Sink>::close
             at /home/qupeng/.cargo/registry/src/github.com-1ecc6299db9ec823/grpcio-0.1.0/src/call/client.rs:309
  10: client::test_cstream_sync
             at src/client/main.rs:70
  11: client::main
             at src/client/main.rs:98
  12: __rust_maybe_catch_panic
             at /checkout/src/libpanic_unwind/lib.rs:99
  13: std::rt::lang_start
             at /checkout/src/libstd/panicking.rs:459
             at /checkout/src/libstd/panic.rs:361
             at /checkout/src/libstd/rt.rs:61
  14: main
  15: __libc_start_main
  16: _start

Expose document of `StreamingCallSink`

According to official doc site, there is no document about StreamingCallSink.
After check the source code, I know it's a implemention of futures::stream::Sink.
So do you think expose this into document is a good idea? @BusyJay If so, I can do this.

centos6 build and link grpc-rs source code error: undefined reference to `__gxx_personality_v0'

hi, I use grpc-rs source code as grpcio's patch in my rust project, after complie succ . the link occur error, detail as below:
the grpcio use method in my project Cargo.toml is

...
[dependencies]
grpcio = "*"
...
[patch.crates-io]
grpcio = { path = "./grpc-rs" }

My build machine os is centos 6, I upgrade the default gcc/g++ version from 4.47 to 4.8.2:

wget http://people.centos.org/tru/devtools-2/devtools-2.repo -O /etc/yum.repos.d/devtools-2.repo
yum install devtoolset-2-gcc devtoolset-2-binutils
yum install devtoolset-2-gcc-c++ devtoolset-2-binutils
scl enable devtoolset-2 bash

and then upgrade cmake version to 3.10.0-rc4.
Then the compile process of my project is completed succ, but the final link process is error:

Running `rustc --crate-name tt_agentd src/bin/main.rs --crate-type bin --emit=dep-info,link -C debuginfo=2 -C metadata=329f339b6b95c21e -C extra-filename=-329f339b6b95c21e --out-dir /tmp/multipkg/build/tt/target/debug/deps -L dependency=/tmp/multipkg/build/tt/target/debug/deps --extern chrono=/tmp/multipkg/build/tt/target/debug/deps/libchrono-83f205826c8cbe4a.rlib --extern clap=/tmp/multipkg/build/tt/target/debug/deps/libclap-fdb8754d03fe468d.rlib --extern flate2=/tmp/multipkg/build/tt/target/debug/deps/libflate2-ada67b65e8687c66.rlib --extern toml=/tmp/multipkg/build/tt/target/debug/deps/libtoml-01d27e87266f3d49.rlib --extern error_chain=/tmp/multipkg/build/tt/target/debug/deps/liberror_chain-ce7184105e3bc4f5.rlib --extern walkdir=/tmp/multipkg/build/tt/target/debug/deps/libwalkdir-d5b4fa10edee569d.rlib --extern protobuf=/tmp/multipkg/build/tt/target/debug/deps/libprotobuf-328e3d5ed8378a3e.rlib --extern serde=/tmp/multipkg/build/tt/target/debug/deps/libserde-0291d3120fb722a9.rlib --extern futures=/tmp/multipkg/build/tt/target/debug/deps/libfutures-1b9182b76cdcf9bb.rlib --extern tar=/tmp/multipkg/build/tt/target/debug/deps/libtar-2709790813f55833.rlib --extern tempdir=/tmp/multipkg/build/tt/target/debug/deps/libtempdir-8121eea7baa9d710.rlib --extern grpcio=/tmp/multipkg/build/tt/target/debug/deps/libgrpcio-764d63f6dc20aa0a.rlib --extern hostname=/tmp/multipkg/build/tt/target/debug/deps/libhostname-dc250aee9cb87a9a.rlib --extern tt_proto=/tmp/multipkg/build/tt/target/debug/deps/libtt_proto-6fcd2500f251c566.rlib --extern serde_json=/tmp/multipkg/build/tt/target/debug/deps/libserde_json-ca366df264a2aff6.rlib --extern lazy_static=/tmp/multipkg/build/tt/target/debug/deps/liblazy_static-32480de9118a066c.rlib --extern crypto=/tmp/multipkg/build/tt/target/debug/deps/libcrypto-1dcbab75c663e65b.rlib --extern log=/tmp/multipkg/build/tt/target/debug/deps/liblog-76d0e5da518c9890.rlib --extern env_logger=/tmp/multipkg/build/tt/target/debug/deps/libenv_logger-30dd2c8d8b73c017.rlib --extern daemonize=/tmp/multipkg/build/tt/target/debug/deps/libdaemonize-2ee63a9a17dd392a.rlib --extern serde_derive=/tmp/multipkg/build/tt/target/debug/deps/libserde_derive-3331a53d2a1fcf4d.so --extern rayon=/tmp/multipkg/build/tt/target/debug/deps/librayon-4d01f1358960ca65.rlib --extern log4rs=/tmp/multipkg/build/tt/target/debug/deps/liblog4rs-f6ef6bdbff08160d.rlib --extern tt=/tmp/multipkg/build/tt/target/debug/deps/libtt-aee6ced0a9b80889.rlib -L native=/tmp/multipkg/build/tt/target/debug/build/backtrace-sys-943860c9c514961f/out/.libs -L native=/tmp/multipkg/build/tt/target/debug/build/miniz-sys-c1d19ab19aea7dca/out -L native=/tmp/multipkg/build/tt/target/debug/build/grpcio-sys-a451e038565f03cc/out/build -L native=/tmp/multipkg/build/tt/target/debug/build/grpcio-sys-a451e038565f03cc/out/build/third_party/cares -L native=/tmp/multipkg/build/tt/target/debug/build/grpcio-sys-a451e038565f03cc/out/build/third_party/zlib -L native=/tmp/multipkg/build/tt/target/debug/build/grpcio-sys-a451e038565f03cc/out/build/third_party/boringssl/ssl -L native=/tmp/multipkg/build/tt/target/debug/build/grpcio-sys-a451e038565f03cc/out/build/third_party/boringssl/crypto -L native=/tmp/multipkg/build/tt/target/debug/build/grpcio-sys-a451e038565f03cc/out -L native=/tmp/multipkg/build/tt/target/debug/build/rust-crypto-c61e52eda4d55a33/out`
error: linking with `cc` failed: exit code: 1
  |
  = note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib" "/tmp/multipkg/build/tt/target/debug/deps/tt_agentd-329f339b6b95c21e.0.o" "-o" "/tmp/multipkg/build/tt/target/debug/deps/tt_agentd-329f339b6b95c21e" "/tmp/multipkg/build/tt/target/debug/deps/tt_agentd-329f339b6b95c21e.crate.allocator.o" "-Wl,--gc-sections" "-pie" "-Wl,-z,relro,-z,now" "-nodefaultlibs" "-L" "/tmp/multipkg/build/tt/target/debug/deps" "-L" "/tmp/multipkg/build/tt/target/debug/build/backtrace-sys-943860c9c514961f/out/.libs" "-L" "/tmp/multipkg/build/tt/target/debug/build/miniz-sys-c1d19ab19aea7dca/out" "-L" "/tmp/multipkg/build/tt/target/debug/build/grpcio-sys-a451e038565f03cc/out/build" "-L" "/tmp/multipkg/build/tt/target/debug/build/grpcio-sys-a451e038565f03cc/out/build/third_party/cares" "-L" "/tmp/multipkg/build/tt/target/debug/build/grpcio-sys-a451e038565f03cc/out/build/third_party/zlib" "-L" "/tmp/multipkg/build/tt/target/debug/build/grpcio-sys-a451e038565f03cc/out/build/third_party/boringssl/ssl" "-L" "/tmp/multipkg/build/tt/target/debug/build/grpcio-sys-a451e038565f03cc/out/build/third_party/boringssl/crypto" "-L" "/tmp/multipkg/build/tt/target/debug/build/grpcio-sys-a451e038565f03cc/out" "-L" "/tmp/multipkg/build/tt/target/debug/build/rust-crypto-c61e52eda4d55a33/out" "-L" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "/tmp/multipkg/build/tt/target/debug/deps/libtt-aee6ced0a9b80889.rlib" "/tmp/multipkg/build/tt/target/debug/deps/libcrypto-1dcbab75c663e65b.rlib" "/tmp/multipkg/build/tt/target/debug/deps/librayon-4d01f1358960ca65.rlib" "/tmp/multipkg/build/tt/target/debug/deps/libwalkdir-d5b4fa10edee569d.rlib" "/tmp/multipkg/build/tt/target/debug/deps/libsame_file-51f0c58ca561678c.rlib" "/tmp/multipkg/build/tt/target/debug/deps/libdaemonize-2ee63a9a17dd392a.rlib" "/tmp/multipkg/build/tt/target/debug/deps/liberror_chain-ce7184105e3bc4f5.rlib" "/tmp/multipkg/build/tt/target/debug/deps/libbacktrace-0a24a00d800c5483.rlib" "/tmp/multipkg/build/tt/target/debug/deps/libcfg_if-39407a6f5c167a50.rlib" "/tmp/multipkg/build/tt/target/debug/deps/liblog4rs-f6ef6bdbff08160d.rlib" "/tmp/multipkg/build/tt/target/debug/deps/libserde_value-b4c3e2e6c4050fd6.rlib" "/tmp/multipkg/build/tt/target/debug/deps/libordered_float-20975675ecb44655.rlib" "/tmp/multipkg/build/tt/target/debug/deps/libserde_yaml-956020bc20e32987.rlib" "/tmp/multipkg/build/tt/target/debug/deps/libyaml_rust-538e4354afb6f8e7.rlib" "/tmp/multipkg/build/tt/target/debug/deps/liblinked_hash_map-1d5a8c1b2061c143.rlib" "/tmp/multipkg/build/tt/target/debug/deps/libtypemap-fb4413453ccfec24.rlib" "/tmp/multipkg/build/tt/target/debug/deps/libunsafe_any-7e9009d4aefe1b79.rlib" "/tmp/multipkg/build/tt/target/debug/deps/libtraitobject-72ce215889980bac.rlib" "/tmp/multipkg/build/tt/target/debug/deps/libfnv-ce6acad4e6f3bda9.rlib" "/tmp/multipkg/build/tt/target/debug/deps/libcrossbeam-c2ae04e975406371.rlib" "/tmp/multipkg/build/tt/target/debug/deps/libantidote-f05920b405dc5e0e.rlib" "/tmp/multipkg/build/tt/target/debug/deps/liblog_mdc-5d3a1a124d9e6986.rlib" "/tmp/multipkg/build/tt/target/debug/deps/libtt_proto-6fcd2500f251c566.rlib" "/tmp/multipkg/build/tt/target/debug/deps/libgrpcio-764d63f6dc20aa0a.rlib" "/tmp/multipkg/build/tt/target/debug/deps/libgrpcio_sys-6ef1eac6776f3a8d.rlib" "/tmp/multipkg/build/tt/target/debug/deps/libfutures-1b9182b76cdcf9bb.rlib" "/tmp/multipkg/build/tt/target/debug/deps/libprotobuf-328e3d5ed8378a3e.rlib" "/tmp/multipkg/build/tt/target/debug/deps/liblog-76d0e5da518c9890.rlib" "/tmp/multipkg/build/tt/target/debug/deps/libbacktrace_sys-d7c5f51e838320b6.rlib" "/tmp/multipkg/build/tt/target/debug/deps/libserde_json-ca366df264a2aff6.rlib" "/tmp/multipkg/build/tt/target/debug/deps/libdtoa-c31ef64067a24d52.rlib" "/tmp/multipkg/build/tt/target/debug/deps/libitoa-bb9fe302248b7433.rlib" "/tmp/multipkg/build/tt/target/debug/deps/libserde-0291d3120fb722a9.rlib" "/tmp/multipkg/build/tt/target/debug/deps/libhostname-dc250aee9cb87a9a.rlib" "/tmp/multipkg/build/tt/target/debug/deps/librustc_serialize-5c7e94e54f3b2493.rlib" "/tmp/multipkg/build/tt/target/debug/deps/librustc_demangle-83d9ff7249781958.rlib" "/tmp/multipkg/build/tt/target/debug/deps/libhumantime-f510abbb8fd521fa.rlib" "/tmp/multipkg/build/tt/target/debug/deps/libquick_error-bbcdf42bf963990f.rlib" "/tmp/multipkg/build/tt/target/debug/deps/libchrono-6e3e657de0abbfe7.rlib" "/tmp/multipkg/build/tt/target/debug/deps/libnum-7010fdbf340ca145.rlib" "/tmp/multipkg/build/tt/target/debug/deps/libnum_iter-26dbda985b5a9acf.rlib" "/tmp/multipkg/build/tt/target/debug/deps/libnum_integer-97e8ea1ab5063056.rlib" "/tmp/multipkg/build/tt/target/debug/deps/libnum_traits-6fd04028b4ec4415.rlib" "/tmp/multipkg/build/tt/target/debug/deps/libtime-0cd5fac6e6ca5103.rlib" "/tmp/multipkg/build/tt/target/debug/deps/libflate2-ada67b65e8687c66.rlib" "/tmp/multipkg/build/tt/target/debug/deps/libminiz_sys-50ff439e51f909c5.rlib" "/tmp/multipkg/build/tt/target/debug/deps/liblinked_hash_map-1b499928685848af.rlib" "/tmp/multipkg/build/tt/target/debug/deps/libunreachable-3bde6d0dca5f0eff.rlib" "/tmp/multipkg/build/tt/target/debug/deps/libvoid-4861444fc46bd06e.rlib" "/tmp/multipkg/build/tt/target/debug/deps/librayon_core-3f80a41970af947d.rlib" "/tmp/multipkg/build/tt/target/debug/deps/libnum_cpus-2f6edb1d9f9d0ac0.rlib" "/tmp/multipkg/build/tt/target/debug/deps/liblazy_static-32480de9118a066c.rlib" "/tmp/multipkg/build/tt/target/debug/deps/libcoco-bc6af71e91a88e9c.rlib" "/tmp/multipkg/build/tt/target/debug/deps/libscopeguard-a99cb6da8aacdf01.rlib" "/tmp/multipkg/build/tt/target/debug/deps/libeither-8b850cc8c54085ac.rlib" "/tmp/multipkg/build/tt/target/debug/deps/librand-b0b8180ea869605f.rlib" "/tmp/multipkg/build/tt/target/debug/deps/liblibc-42ccb1ab9c602896.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-8eeda694d27cc3ba.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-d9be38a491a6b20b.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc_jemalloc-7df0812865be3e74.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-1768097fd1bb5d0a.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc_system-38bc2ffba7aac62a.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-d4f79324c33264e2.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-e2edf8b78eb9a037.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd_unicode-29181a531b1322da.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/librand-30d6b4a7069ee56b.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-ac3876fe094f9f74.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-4917ae9e58e9366a.rlib" "-Wl,-Bdynamic" "-l" "util" "-l" "util" "-l" "dl" "-l" "rt" "-l" "pthread" "-l" "pthread" "-l" "gcc_s" "-l" "c" "-l" "m" "-l" "rt" "-l" "pthread" "-l" "util"
  = note: /tmp/multipkg/build/tt/target/debug/deps/libgrpcio_sys-6ef1eac6776f3a8d.rlib(lame_client.cc.o):(.data.DW.ref.__gxx_personality_v0[DW.ref.__gxx_personality_v0]+0x0): undefined reference to `__gxx_personality_v0'
          collect2: error: ld returned 1 exit status
          

error: aborting due to previous error

error: Could not compile `tt`.

Besides, in centos 7 machine, the build and link is ok.