ah.Got it. set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -s") does the job.
среда, 15 марта 2023 г. в 20:22:59 UTC+3, Dmitry Gorelov: > Dear Sirs, please share with the community ))) How could you strip > binaries to size of 800kb? > > вторник, 19 сентября 2017 г. в 12:09:40 UTC+3, uttav.a...@gmail.com: > >> Hi Xuejie Xiao, >> Could you please tell how did you reduce the binary size to 800KB. >> I have tried to build with strip-static option, and then compiling client >> with g++ -s . I am trying to compile the helloworld example. >> But the size I am getting is 4.9 MB minimum which is still bigger than >> what we require. >> Could you please share some info how you have built your client ? >> >> >> On Wednesday, July 22, 2015 at 9:53:40 PM UTC+5:30, Xuejie Xiao wrote: >>> >>> Nicolas: >>> >>> Thanks for the detailed explanation! Actually I was being silly here, it >>> is indeed the problem of debug symbols. With a single `-s` flag, I can >>> strip the binary from around ~ 9M down to ~800K. This is quite reasonable >>> for us. >>> >>> Thanks again for all the help! >>> >>> On Wed, Jul 22, 2015 at 11:13 PM, Nicolas Noble <pixel...@gmail.com> >>> wrote: >>> >>>> For the server part, the linker will already do what you want, really. >>>> If you're not using any of the server function in your binary, with the >>>> way >>>> gRPC works and is setup, while statically linking, the linker will remove >>>> any unused function and the server code will disappear. But the gain >>>> should >>>> really be negligible. The "server-specific" code I I'm talking about here >>>> is but a few lines of code to set up a listener socket, and accepting >>>> connections on it. >>>> >>>> One of the problems of OpenSSL is its registration system, meaning that >>>> we're dragging with us an insane amount of unwanted features. It may be >>>> possible to shrink down the size of the library by tweaking the >>>> compilation >>>> of OpenSSL to cull all of the unnecessary parts that the linker can't >>>> remove due to the registration. But the current way we're embedding >>>> OpenSSL >>>> into gRPC is more of a convenience than something that should be used in >>>> production. What you really want is to rely on the presence of the OpenSSL >>>> dynamic library on your client's machines, and make usage of our NPN >>>> fallback mechanism. >>>> >>>> Basically, remove or rename openssl from third_party (or don't >>>> recursively clone the repository). You'll have to make sure you have >>>> openssl-dev installed, and you'll have to link with openssl yourself, but >>>> then you'll be using the system-wide, well known OpenSSL, hence reducing >>>> the size of your binary. >>>> >>>> As for using another library than OpenSSL, contributions are welcome >>>> :-) The relevant code is going to be in src/core/security and >>>> src/core/tsi. >>>> But this is probably going to be the same issue. In fact, our choice of >>>> OpenSSL is only because it's a usually widely installed SSL library, and >>>> we >>>> don't have to embed it. As I said, we're only embedding it for convenience >>>> and test reproducibility. If we were to use another SSL library that we >>>> know we'd always embed instead of relying on system-wide libraries, we'd >>>> use Google's BoringSSL otherwise :-) >>>> >>>> Last but not least, if you statically linked, remember to strip your >>>> binary. The libraries are compiled with debug symbols in by default, and >>>> stripped only during installation, just like any other package. Meaning >>>> that if you skip the installation phase, your libraries won't be stripped >>>> out of their debugging information, and will drastically bloat your final >>>> binary. >>>> >>>> On Wed, Jul 22, 2015 at 6:26 AM, Xuejie "Rafael" Xiao <xxu...@gmail.com >>>> > wrote: >>>> >>>>> Oops, I must admin that I overlooked the OpenSSL size part in my >>>>> previous email, so I *have* to send another email. I just wish we have an >>>>> "undo" button for mailing lists :) >>>>> >>>>> From Nicolas' numbers, it would seem OpenSSL indeed bring a lot of >>>>> size. I'm not so familiar with gRPC internals as well as HTTP/2 >>>>> encryption, >>>>> so please forgive me if this sounds silly: what features are required by >>>>> gRPC in a SSL library? You mentioned ALPN support here, so do you think >>>>> it >>>>> will be an easy task to switch to a different SSL library that also has >>>>> ALPN support, such as MatrixSSL or mbed TLS? Considering those SSL >>>>> library >>>>> is smaller than OpenSSL, we should expect a smaller binary size, >>>>> shouldn't >>>>> we? >>>>> >>>>> On Wed, Jul 22, 2015 at 6:49 PM, Xuejie "Rafael" Xiao < >>>>> xxu...@gmail.com> wrote: >>>>> >>>>>> Craig & Nicolas: >>>>>> >>>>>> Thank you both for your reply! I will use one post to reply to you >>>>>> both to save everyone from one extra email :) >>>>>> >>>>>> I understand that dynamic linking might be able to solve the problem. >>>>>> However, we are now thinking of using gRPC as an *external* RPC protocol >>>>>> instead of an *internal* one. This means that the client side binary >>>>>> will >>>>>> be installed on end user's machine. In this case, I think every byte we >>>>>> save will count, and dynamic linking is really not an option for us >>>>>> here(user will still have to install gRPC as well as OpenSSL). >>>>>> >>>>>> Craig: I know this might be too early to tell, but just curious >>>>>> enough to ask: how much of the codebase do you think only relate to >>>>>> server >>>>>> hence can be stripped from the client? In other words, is there any >>>>>> estimation you have on how small the client binary can be, assuming the >>>>>> fact you guys have the time for this next quarter? >>>>>> >>>>>> Or maybe we are just using gRPC in the wrong place :P >>>>>> >>>>>> On Wed, Jul 22, 2015 at 1:14 PM, Nicolas Noble <pixel...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> Also, it seems that you'd be compiling / linking against the static >>>>>>> version of the library ? The grpc shared libraries, once installed, >>>>>>> should >>>>>>> be considerably smaller, and wouldn't have an impact on your binary >>>>>>> size. >>>>>>> >>>>>>> Right now if I compile grpc, I get the following: >>>>>>> >>>>>>> $ ls -lah *.so.0.10.0.0 >>>>>>> -rwxrwxr-x 1 pixel pixel 51K Jul 22 07:11 libgpr.so.0.10.0.0 >>>>>>> -rwxrwxr-x 1 pixel pixel 2.5M Jul 22 07:11 libgrpc.so.0.10.0.0 >>>>>>> -rwxrwxr-x 1 pixel pixel 229K Jul 22 07:11 libgrpc++.so.0.10.0.0 >>>>>>> -rwxrwxr-x 1 pixel pixel 287K Jul 22 07:11 >>>>>>> libgrpc_unsecure.so.0.10.0.0 >>>>>>> -rwxrwxr-x 1 pixel pixel 205K Jul 22 07:11 >>>>>>> libgrpc++_unsecure.so.0.10.0.0 >>>>>>> >>>>>>> And this is with OpenSSL embedded. >>>>>>> >>>>>>> If I remove the embedded OpenSSL, and fallback on NPN, hence using >>>>>>> the system's OpenSSL, as Craig mentioned, I get only this: >>>>>>> >>>>>>> $ ls -lah *.so.0.10.0.0 >>>>>>> -rwxrwxr-x 1 pixel pixel 51K Jul 22 07:12 libgpr.so.0.10.0.0 >>>>>>> -rwxrwxr-x 1 pixel pixel 405K Jul 22 07:12 libgrpc.so.0.10.0.0 >>>>>>> -rwxrwxr-x 1 pixel pixel 229K Jul 22 07:12 libgrpc++.so.0.10.0.0 >>>>>>> -rwxrwxr-x 1 pixel pixel 287K Jul 22 07:12 >>>>>>> libgrpc_unsecure.so.0.10.0.0 >>>>>>> -rwxrwxr-x 1 pixel pixel 205K Jul 22 07:12 >>>>>>> libgrpc++_unsecure.so.0.10.0.0 >>>>>>> >>>>>>> As expected, only the grpc library shrunk down in size, from 2.5M to >>>>>>> 405K. >>>>>>> >>>>>>> So something would seem off with your numbers in all cases. >>>>>>> >>>>>>> On Tue, Jul 21, 2015 at 7:03 PM, 'Craig Tiller' via grpc.io < >>>>>>> grp...@googlegroups.com> wrote: >>>>>>> >>>>>>>> Hey! >>>>>>>> >>>>>>>> We haven't spent a huge amount of time optimizing for size, but I >>>>>>>> expect to do some work in that direction in the coming quarter (or so). >>>>>>>> >>>>>>>> That said, most of our code base is relatively symmetric, so I >>>>>>>> don't expect to see massive differences in client and servers for the >>>>>>>> greeter example. >>>>>>>> >>>>>>>> Most of the existing cost is OpenSSL I expect. If you can rely on >>>>>>>> the system library (and therefore don't mind using npn instead of >>>>>>>> alpn) - >>>>>>>> or if you don't need crypto and auth - then that cost goes way down. >>>>>>>> >>>>>>>> If you do need alpn (its required by http2, so as soon as you need >>>>>>>> ssl and don't control all intermediaries you may), then that cost is >>>>>>>> going >>>>>>>> to be there. You might be able to amortize that cost if any other >>>>>>>> library >>>>>>>> you're considering also needs to link a recentish OpenSSL. >>>>>>>> >>>>>>>> On Tue, Jul 21, 2015, 6:11 PM Xuejie Xiao <xxu...@gmail.com> wrote: >>>>>>>> >>>>>>>>> Hey guys! >>>>>>>>> >>>>>>>>> We are evaluating gRPC internally, one thing we've found out, is >>>>>>>>> that the compile C++ binary size is quite big, this is even the case >>>>>>>>> for >>>>>>>>> client binaries. For example, if we compile the C++ helloworld >>>>>>>>> example from >>>>>>>>> grpc-common repo, greeter_client will be 9.4M, while greeter_server >>>>>>>>> is 9.5M. >>>>>>>>> >>>>>>>>> So our question here is: is it true that the client-side binary >>>>>>>>> requires almost the same binary size as the server-side binary? Is it >>>>>>>>> possible to strip the client binary size here? >>>>>>>>> >>>>>>>>> Or maybe we are actually using a wrong linking argument here? >>>>>>>>> >>>>>>>>> Many thanks! >>>>>>>>> >>>>>>>>> -- >>>>>>>>> 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 grpc-io+u...@googlegroups.com. >>>>>>>>> To post to this group, send email to grp...@googlegroups.com. >>>>>>>>> To view this discussion on the web visit >>>>>>>>> https://groups.google.com/d/msgid/grpc-io/47b360e7-8332-449d-b444-060ec98c45ab%40googlegroups.com >>>>>>>>> >>>>>>>>> <https://groups.google.com/d/msgid/grpc-io/47b360e7-8332-449d-b444-060ec98c45ab%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>>> . >>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>>> >>>>>>>> -- >>>>>>>> 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 grpc-io+u...@googlegroups.com. >>>>>>>> To post to this group, send email to grp...@googlegroups.com. >>>>>>>> To view this discussion on the web visit >>>>>>>> https://groups.google.com/d/msgid/grpc-io/CAAvp3oNkLi9iAuajBcrogJddk_AoTLUetDncs857w55tG8qhHw%40mail.gmail.com >>>>>>>> >>>>>>>> <https://groups.google.com/d/msgid/grpc-io/CAAvp3oNkLi9iAuajBcrogJddk_AoTLUetDncs857w55tG8qhHw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>> . >>>>>>>> >>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best Regards, >>>>>> >>>>>> Xuejie "Rafael" Xiao >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Best Regards, >>>>> >>>>> Xuejie "Rafael" Xiao >>>>> >>>>> >>>> >>> >>> >>> -- >>> Best Regards, >>> >>> Xuejie "Rafael" Xiao >>> >>> -- 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 grpc-io+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/3d267031-58f1-43cf-b6cd-e7160139f033n%40googlegroups.com.