[Buildroot] [autobuild.buildroot.net] Build results for 2017-03-17

Arnout Vandecappelle arnout at mind.be
Sat Mar 18 16:19:59 UTC 2017



On 18-03-17 17:02, Waldemar Brodkorb wrote:
> Hi Arnout,
> Arnout Vandecappelle wrote,
> 
>>
>>
>> On 18-03-17 08:28, Thomas Petazzoni wrote:
>>> microblazeel |                nfs-utils-1.3.3 | NOK | http://autobuild.buildroot.net/results/240cfb0497b1dd7b5b33b8f64635cca435d49f05
>>
>>  I looked at this one and I'm a bit stumped. This is the error:
>> .../sysroot/usr/lib/libc.a(clnt_simple.os): In function `callrpc':
>> (.text+0x0): multiple definition of `callrpc'
>> .../sysroot/usr/lib/libtirpc.a(libtirpc_la-rpc_soc.o):(.text+0x784): first
>> defined here
>> (and many more like that).
>>
>>  It's a bit weird that this object file from the C library even gets linked in.
>> The Map file says:
>>
>> .../sysroot/usr/lib/libc.a(rpc_thread.os)
>> 	.../sysroot/usr/lib/libc.a(cancel.os) (__rpc_thread_destroy)
>> (skipping a few levels of indirection here).
>>
>>  So somehow the pthread library is pulling in the RPC support from uClibc, which
>> obviously conflicts with tirpc.
> 
> But if BR2_TOOLCHAIN_EXTERNAL_INET_RPC=y is active, isn't uClibc-ng
> build with RPC support? If this is the case, you end up with two RPC
> implememtations. That should be handled by Buildroot.
> 
> Do you have support for use either libtirpc or uClibc-ng internal
> RPC support?

 rpcbind need libtirpc for RPC support, it can't use the toolchain RPC for some
reason. That's why both implementations are there.

 Normally it shouldn't be an issue to have two implementations. Since the one
from libtirpc is linked in before libc is linked in, the one from libc isn't
going to be used. This works for musl AFAICS.

 The problem is that with uClibc-ng on microblaze, RPC from libc is linked in
unconditionally (from pthreads, AFAICS). Check e.g. busybox, it has
rpc_thread.os, rpc_commondata.os, rpc_prot.os and rpc_dtablesize.os. uClibc-ng
on ARC, for example, doesn't seem to have this.

 So it's the __rpc_thread_destroy in cancel.os that seems to be the problem here.

 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF



More information about the buildroot mailing list