#grpc

hey i'm trying to build grpc on linux, and i'm getting this error: ... arm-arm1176jzs-linux-gnueabi-ar: invalid option -- '/'

does that look familiar to anyone?

yhou're trying to cross compile, aren't you ?

|Pixel|_: i am, but i figured it out.

is it possible to build w/o openssl?

yes

but what are you trying to do exactly ?

i have a small handheld terminal i'm writing an rpc server for.

it will only be used during development so security is not an issue

which language ?

oh c++

okay

try make grpc++_unsecure

"no rule to make...

yep, okay

make libs/opt/libgrpc++_unsecure.a ?

same

erm

oh, right

hmm. NO_SECURE

make `pwd`/libs/opt/libgrpc++_unsecure.a

that got me closer

yea /

?

was the right target

so now protobuf is being a pita

yep, sorry :)

oh i have to specify --host, etc

forgot about that

compile it separately

good idea

if you install it and all, the Makefile should detect it and be happy and not try to compile the one in third_party

i'd need to get the makefile to point to my sysroot

oh actually it should automatically

this is just an insane build system

a 15k line makefile..

hello

does anyone grpc in android?

Does anyone use grpc in Android?

hello

anyone here?

Yes.

grpcer But in general, it is good advice to ask and wait ;)

oh

i asked on google group

so i came here if i can get some help faster haha

Can a request sent to Server-A be completed/responded by Server-B (with grpc)?

you could theorically build something that does that

you could have a forwarder system for instance

where in your example, A acts as a proxy for B

I see.

Another question,

Can a Request sent in one TCP socket be responded through another TCP socket?

For example, if a TCP socket dies in between performing a long running job

can server send respond over the re-established TCP socket?/

bvk: No. The RPC dies with the TCP connection.

bvk: We have a (not yet available to you) implementation of gRPC on Android that can use Cronet (https://chromium.googlesource.com/chromium/src/...). That allows you to use QUIC with UDP.

UDP then doesn't have the same sort of "socket death" as TCP. But even when using Cronet, some devices will be on a network where QUIC is broken and have to fall-back to HTTP/2 over TCP.

any ideas on how i might be able to get grpc to pick up a specific install of protobuf?

JakeSays: What language?

c++

For use when compiling?

Or for when running protoc?

Or linking :)

i'm cross compiling grpc. it fails building protobuf

./configuring

Ah.

grpc doesnt pass on the required flags

so i built protobuf separately and installed it in my sysroot

but grpc still tries to build protobuf

I'm pretty sure if you trash the protobuf submodule, grpc will try to use the system protobuf. But I think there is a flag as well. Looking...

I can't find the flag. Simply doing `mv third_party/protobuf third_party/protobuf.disabled' would be my hack :)

But I mainly work on Java.

JakeSays: ^^

i'll give it a try. thanks

I was actually told the flag on Thursday or Friday, but I didn't really need to remember it so I forgot it.

i wish grpc would switch to gn from a 15k make file.

er, 15k line

JakeSays: The gRPC build system is a semi-clone of GYP. Because it is 2016 and build systems aren't a solved problem.

I think at this point "it works, so don't spend a ton of time re-inventing it" is the feeling.

We're waiting some for Bazel to mature enough where we can swap to it, although I think we will then be using it as the source-of-truth instead of build.yaml (still supporting the huge makefile)

That's a ways out, and is sort of pie-in-the-sky for the moment.

ejona: actually it only works if you're either doing the defaults or are intimately familiar with it.

(And I don't truly know what I'm talking about, since I work on grpc-java where Gradle is working and we're just happy not to be using Maven or Ant)

otherwise its a total time sink

the only way i'll be able to keep using it is if i rewrite the build system.

I don't completely disagree with you. It seems that would be the case with almost every build system.

thats not true

systems like gn, while they do require some effort to understand, they're easy to pick up.

The Makefile is not the build system. That is just one supported output of the system. msbuild is another, for example.

In the same way that gn produces Ninja

well, i'm on linux - it comes with that makefile, and no instructions to use anything but.

But yes, it is unweildy. But it is also hard to support all the platforms _and_ languages.

Yes, and you are cross-compiling, which is always fun.

i was able to cross compile chromium using the same toolchain in less time than i've spent just understanding this makefile.

GN is _very new_. We are reasonably aware of what's happening elsewhere, but at the time we started GYP was the closest that would serve our needs.

It does help that GN has some bits of documentation for cross-compiling.

well shit - i got it picking up the sysroot, but now it won't build the cpp generator: /usr/include/c++/5/memory:117:58: error: cast from ‘void*’ to ‘uintptr_t {aka unsigned int}’

But really, we don't want to be build system developers. So we're certainly wanting to ditch what we have as soon as we can .

That's an... interesting... error.

yup