: unrecognized option '-Wl,-soname,libgpr.so.1

[Pietro]

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 ?

[Nicolas Noble]

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.

--
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.
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.

[Pietro]

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.

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.

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 ?

[Nicolas Noble]

On Tue, Sep 6, 2016 at 3:24 AM, Pietro <pulsar...@posteo.net> 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.

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...

 

>     send an email to grpc-io+unsubscribe@googlegroups.com.

>     To post to this group, send email to grp...@googlegroups.com.
>     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 grpc-io+unsubscribe@googlegroups.com.

To post to this group, send email to grp...@googlegroups.com.
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.

[Lars Seipel]

On Mon, Sep 05, 2016 at 01:05:04PM +0000, Pietro wrote:
> arm-phytec-linux-gnueabi-ld
> : unrecognized option '
> -Wl,-soname,libgpr.so.1

That specific error is likely avoided by using the gcc or g++ compiler
drivers (as appropriate) instead of plain ld.

> Shouldn't that line be -soname=libgrp.so ?

The -Wl flag instructs the driver program to pass through the arguments
(-soname and libgpr.so.1) to ld, so the resulting ld command line will
contain "-soname libgpr.so.1".

[Nicolas Noble]

D'oh, thank you, I didn't spot that he was directly using ld instead of gcc.

--
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+unsubscribe@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
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/20160907192836.GA1331%40propane.slrz.net.

[Pietro]

When cross compiling and passing the AR variable from the make command
line I had to apply the follwing patch :

diff --git a/Makefile b/Makefile
index 2dc401a..e1f0755 100644
--- a/Makefile
+++ b/Makefile
@@ -283,6 +283,8 @@ LDXX ?= $(LDXX_$(CONFIG))
ifeq ($(SYSTEM),Linux)
ifeq ($(origin AR), default)
AR = ar rcs
+else
+override AR += rcs
endif
STRIP ?= strip --strip-unneeded
else

Otherwise the AR tool does not get any command to be executed and it
will print its helper.

I am not sure that is the best approach I wanted to share it tough.

Nicolas Noble <pixel...@gmail.com> writes:

> D'oh, thank you, I didn't spot that he was directly using ld instead
> of gcc.
>
> On Wed, Sep 7, 2016 at 12:28 PM, Lars Seipel <lars....@gmail.com>
> wrote:
>
> On Mon, Sep 05, 2016 at 01:05:04PM +0000, Pietro wrote:
> > arm-phytec-linux-gnueabi-ld
> > : unrecognized option '
> > -Wl,-soname,libgpr.so.1
>
> That specific error is likely avoided by using the gcc or g++
> compiler
> drivers (as appropriate) instead of plain ld.
>
> > Shouldn't that line be -soname=libgrp.so ?
>
> The -Wl flag instructs the driver program to pass through the
> arguments
> (-soname and libgpr.so.1) to ld, so the resulting ld command line
> will
> contain "-soname libgpr.so.1".
>
> --
> 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.

[Pietro]

Nicolas Noble <pixel...@gmail.com> writes:

> On Tue, Sep 6, 2016 at 3:24 AM, Pietro <pulsar...@posteo.net>
> 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.

Thanks.

> > send an email to grpc-io+u...@googlegroups.com.

> > To post to this group, send email to grp...@googlegroups.com.
> > 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 grpc-io+u...@googlegroups.com.

> To post to this group, send email to grp...@googlegroups.com.
> 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

[abhinava.s...@gmail.com]

Helpful thread! I just spent a whole lot of time getting this to work (latest GRPC and ProtoBuf), cross-compiling for ARM.

Seems like the trick is to use gcc and g++ as linker rather than directly using 'ld'.

I followed the OP's make invocation here - https://github.com/grpc/grpc/issues/13436

The two changes I did are as follows: make HAS_PKG_CONFIG=false CC=arm-linux-gnueabi-gcc CXX=arm-linux-gnueabi-g++ RANLIB=arm-linux-gnueabi-ranlib LD=arm-linux-gnueabi-gcc LDXX=arm-linux-gnueabi-g++ AR=arm-linux-gnueabi-ar PROTOBUF_CONFIG_OPTS="--host=arm-linux-gnueabi --with-protoc=/usr/local/bin/protoc" static

I was able to produce both static and shared objects (by passing the 'static' option or without the 'static' option).

This whole process is like black magic! Can the GRPC team put a better porting guide than having to use the Makefile? Specifically, what make environment variables to set/unset, how to compile/install for the host first and then cross-compile for the target etc.

On Wednesday, September 7, 2016 at 1:25:55 PM UTC-7, Nicolas Noble wrote:

D'oh, thank you, I didn't spot that he was directly using ld instead of gcc.

On Wed, Sep 7, 2016 at 12:28 PM, Lars Seipel <lars....@gmail.com> wrote:

On Mon, Sep 05, 2016 at 01:05:04PM +0000, Pietro wrote:
> arm-phytec-linux-gnueabi-ld
> : unrecognized option '
> -Wl,-soname,libgpr.so.1

That specific error is likely avoided by using the gcc or g++ compiler
drivers (as appropriate) instead of plain ld.

> Shouldn't that line be -soname=libgrp.so ?

The -Wl flag instructs the driver program to pass through the arguments
(-soname and libgpr.so.1) to ld, so the resulting ld command line will
contain "-soname libgpr.so.1".

--
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.
Visit this group at https://groups.google.com/group/grpc-io.

[liu.x...@gmail.com]

Hello,

Thx for your post, it is helpful. after cross-compilation of gRPC, I want to do cross-compilation under example/cpp/helloworld using the same make command, and i do modification on Makefile:

make HAS_PKG_CONFIG=false CC=aarch64-himix100-linux-gcc CXX=aarch64-himix100-linux-g++ RANLIB=aarch64-himix100-linux-ranlib LD=aarch64-himix100-linux-ld LDXX=aarch64-himix100-linux-g++  AR=aarch64-himix100-linux-ar PROTOBUF_CONFIG_OPTS="--host=aarch64-himix100-linux --with-protoc=/home/liu/Downloads/grpc-cross/grpc/bins/opt/protobuf/protoc"

and get lots of errors like this:

opt/hisi-linux/x86-arm/aarch64-himix100-linux/aarch64-linux-gnu/include/c++/6.3.0/bits/locale_classes.h:336:12: error: ‘__gthread_once_t’ does not name a type
     static __gthread_once_t _S_once;
            ^~~~~~~~~~~~~~~~

My question 1 is: is it correct to do cross-compilation of helloword using this make command?

and 2 is: what is wrong with errors?

thx a lot