Nicolas Noble <[email protected]> writes:

> On Tue, Sep 6, 2016 at 3:24 AM, Pietro <[email protected]>
> wrote:
>
>     Hi,
>     
>     I am working with an embedded device whose build system is Yocto
>     and my
>     long term goal is to use the gRPC for an small piece of software
>     that
>     will run on the device.
>     
>
> So, I'll say it again: you probably just want to compile the library
> statically. That's going to alleviate a lot of headaches on your end.
> Unless you plan on having a lot of grpc binaries running on your
> embedded device, a shared library won't give you any advantage.
The provided examples use the shared library and I wanted to use them as
they are, I did not think I could be so difficult to get the shared
object.

I have put that task on hold for a little while to get more confidence
with the build system itself as I am mixing too many thing and gRPC
might not be the easiest package to start with.

>
>     I am new to the gRPC library and I have played with the CPP
>     examples on
>     my local machine, the second step would be to make the examples
>     running
>     on the board itself , that done I know I can take it from there
>     and
>     start to write my own application.
>     
>     The gRPC sources compile fine if not cross-compiled and not using
>     the
>     Yocto build system, but when cross compiled I am stumbling on that
>     building error.
>     From what I can see from the building logs the Yocto build seems
>     to
>     compile many more things than the "native" build, for instance the
>     borinssl files are NOT compiled when not cross compiling.
>     
>     Tools' names such as libtoolize and
>     configure.ac are printed out in the build log:
>     
>     
>     | libtoolize: copying file `m4/ltsugar.m4'
>     |
>     | libtoolize: copying file `m4/ltversion.m4'
>     |
>     | libtoolize: copying file `m4/lt~obsolete.m4'
>     
>     
>     | configure.ac:65: installing './ar-lib'
>     |
>     | configure.ac:61: installing './compile'
>     |
>     | configure.ac:46: installing './config.guess'
>     |
>     | configure.ac:46: installing './config.sub'
>     |
>     | configure.ac:48: installing './install-sh'
>     |
>     | configure.ac:48: installing './missing'
>     |
>     | benchmarks/Makefile.am: installing './depcomp'
>     |
>     | parallel-tests: installing './test-driver'
>     
>     
>     
>     ....
>     
>     |
>     | [LD] Linking
>     |
>     
> /export/arm/pietro/PD15.1/build/tmp-glibc/work/cortexa8t2hf-vfp-neon-phytec-
>    linux-gnueabi/libgrpc/1.0.0-r0/git/libs/opt/libgpr.so.1.0.0-pre1
>     |
>     | arm-phytec-linux-gnueabi-ld: unrecognized option '-Wl,-O1'
>     | arm-phytec-linux-gnueabi-ld: use the --help option for usage
>     | information
>     
>     So it looks like the build process is very different in the two
>     cases,
>     do you have any idea about how I could narrow down the problem or
>     avoid
>     to compile too many stuff ? I just want to use gRPC C++ and the
>     libprotobuf is already present in the system.
>     
>
> So, cross compiling anything is always a bit difficult. Even more so
> in the case of gRPC that is two-faced: there's a native part, which is
> the protoc plugin, and a cross-compiled part, which is the library
> itself. Libprotobuf presents the same quality, and some care is
> required to cross compile libprotobuf successfully. You'll need to
> compile and install grpc and protobuf once natively on your host
> machine to get the plugins there, and you'll need to then
> cross-compile the library portion of libprotobuf first, then the
> library portion of grpc.
>
> The gRPC Makefile will attempt to locate libprotobuf on your system.
> You can override this check with the following:
>
> HAS_SYSTEM_PROTOBUF=true make...
>
> You can also simply delete the directory third_party/protobuf, and the
> Makefile will attempt to fallback on what's on your system.
>
> The rest of the dependencies should be easier to cross compile (zlib,
> ssl, ...)
>
>     It might be the compiler used by Yocto isn't right for gRPC :
>     
>     Looking at the Makefile I can see load of lines using the
>     
>     $(Q) (quiet ?)
>     $(E) (echo ?)
>     
>     Which I have never seen, are they built-in make functions ?
>     
>     Is there a way to tell make to show me the full compiler's output ?
>    
>     
>
> This is a typical trick used by various Makefiles around, including
> the Linux Kernel:
>
> ifeq ($(V),1)
> E = @:
> Q =
> else
> E = @echo
> Q = @
> endif
>
> So to display the full command lines, you can do V=1 make...

Thanks.
>
>     
>     
>     
>     
>     
>     
>     
>     "'Nicolas Noble' via grpc.io" <[email protected]> writes:
>     
>     > No, this is correct for building a shared library under Linux.
>     >
>     > Do you really want to build shared libraries? What exactly is
>     the goal
>     > of your cross compilation?
>     >
>     > Most likely, especially if your linker doesn't know about the
>     soname
>     > option, you only need static libraries, so make static should be
>     > enough for you.
>     >
>     > On Mon, Sep 5, 2016, 06:10 Pietro <[email protected]>
>     wrote:
>     >
>     > Hi all,
>     >
>     > I want to cross compile the gRPC library for ARM and I am using
>     > the
>     > Yocto build system.
>     >
>     > The build fails for the following error, which I am suspicious
>     has
>     > something to do with the compiler being used:
>     >
>     >
>     > [LD] Linking
>     >
>     
> /export/arm/xxx/PD15.1/build/tmp-glibc/work/cortexa8t2hf-vfp-neon-phytec-linux-gnueabi/
>    libgrpc/1.0.0-r0/git/libs/opt/libgpr.so.1.0.0-pre1
>     >
>     >
>     > arm-phytec-linux-gnueabi-ld
>     > : unrecognized option '
>     > -Wl,-soname,libgpr.so.1
>     >
>     >
>     > arm-phytec-linux-gnueabi-ld
>     > : use the --help option for usage information
>     >
>     > The problem seems to be caused by the following line in the
>     > makefile:2406
>     >
>     > $(Q) $(LD) $(LDFLAGS) -L$(LIBDIR)/$(CONFIG) -shared
>     > -Wl,-soname,libgpr.so.1 -o
>     > $(LIBDIR)/$(CONFIG)/libgpr$(SHARED_VERSION).$(SHARED_EXT)
>     > $(LIBGPR_OBJS) $(LDLIBS) $(ZLIB_MERGE_LIBS)
>     > Shouldn't that line be -soname=libgrp.so ?
>     >
>     > --
>     > You received this message because you are subscribed to the
>     Google
>     > Groups "grpc.io" group.
>     > To unsubscribe from this group and stop receiving emails from
>     it,
>     > send an email to [email protected].
>     > To post to this group, send email to [email protected].
>     > Visit this group at https://groups.google.com/group/grpc-io.
>     > To view this discussion on the web visit
>     >
>     https://groups.google.com/d/msgid/grpc-io/87shte8pkv.fsf%40posteo.net
>    
>     > .
>     > 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 [email protected].
>     To post to this group, send email to [email protected].
>     Visit this group at https://groups.google.com/group/grpc-io.
>     
>     To view this discussion on the web visit
>     https://groups.google.com/d/msgid/grpc-io/87eg4x8gxc.fsf%40posteo.net
>    .
>     
>     
>     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 [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/878tv27h2j.fsf%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Reply via email to