* [Buildroot] [autobuild.buildroot.net] Build results for 2017-03-17 @ 2017-03-18 7:28 Thomas Petazzoni 2017-03-18 15:15 ` Arnout Vandecappelle 0 siblings, 1 reply; 7+ messages in thread From: Thomas Petazzoni @ 2017-03-18 7:28 UTC (permalink / raw) To: buildroot Hello, Build statistics for 2017-03-17 ================================ successes : 98 failures : 9 timeouts : 0 TOTAL : 107 Classification of failures by reason ==================================== uboot-tools-2017.03 | 4 gdb-7.11.1 | 1 git-2.12.0 | 1 nfs-utils-1.3.3 | 1 qt5webkit-5.8.0 | 1 trinity-v1.6 | 1 Detail of failures =================== x86_64 | gdb-7.11.1 | NOK | http://autobuild.buildroot.net/results/ed8726d4cd536b81a4bca4c3d9056ad4ff2658db arm | git-2.12.0 | NOK | http://autobuild.buildroot.net/results/561d8bfd9a98e0fdbae0e4bdf21aeea297fbf876 microblazeel | nfs-utils-1.3.3 | NOK | http://autobuild.buildroot.net/results/240cfb0497b1dd7b5b33b8f64635cca435d49f05 arm | qt5webkit-5.8.0 | NOK | http://autobuild.buildroot.net/results/3792695078cf3fe7bac255a42c88d4540b5b275f arm | trinity-v1.6 | NOK | http://autobuild.buildroot.net/results/94b4281bc10856d56a7d4abcf269cb5dd584e34e xtensa | uboot-tools-2017.03 | NOK | http://autobuild.buildroot.net/results/5828f903e4f6f548b1f537467603ce5194c95395 powerpc64le | uboot-tools-2017.03 | NOK | http://autobuild.buildroot.net/results/58422d42f8b5543539526f967d0896e4d5371e7e mips64el | uboot-tools-2017.03 | NOK | http://autobuild.buildroot.net/results/42f7c13890c4f935834c16992a6fe00b9f0e15b9 xtensa | uboot-tools-2017.03 | NOK | http://autobuild.buildroot.net/results/3a13ee820973d3cba436e7c35e1f08e90b344b12 -- http://autobuild.buildroot.net ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-03-17 2017-03-18 7:28 [Buildroot] [autobuild.buildroot.net] Build results for 2017-03-17 Thomas Petazzoni @ 2017-03-18 15:15 ` Arnout Vandecappelle 2017-03-18 16:02 ` Waldemar Brodkorb 0 siblings, 1 reply; 7+ messages in thread From: Arnout Vandecappelle @ 2017-03-18 15:15 UTC (permalink / raw) To: buildroot 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. The weird thing is that other packages using libtirpc *don't* fail, e.g. argus. Hm, looks like that one links against libtirpc but doesn't actually use any of its symbols... Waldemar, any idea? 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-03-17 2017-03-18 15:15 ` Arnout Vandecappelle @ 2017-03-18 16:02 ` Waldemar Brodkorb 2017-03-18 16:19 ` Arnout Vandecappelle 0 siblings, 1 reply; 7+ messages in thread From: Waldemar Brodkorb @ 2017-03-18 16:02 UTC (permalink / raw) To: buildroot 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? best regards Waldemar ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-03-17 2017-03-18 16:02 ` Waldemar Brodkorb @ 2017-03-18 16:19 ` Arnout Vandecappelle 2017-03-18 16:33 ` Waldemar Brodkorb 0 siblings, 1 reply; 7+ messages in thread From: Arnout Vandecappelle @ 2017-03-18 16:19 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-03-17 2017-03-18 16:19 ` Arnout Vandecappelle @ 2017-03-18 16:33 ` Waldemar Brodkorb 2017-03-18 17:11 ` Arnout Vandecappelle 0 siblings, 1 reply; 7+ messages in thread From: Waldemar Brodkorb @ 2017-03-18 16:33 UTC (permalink / raw) To: buildroot Hi, > Am 18.03.2017 um 17:19 schrieb Arnout Vandecappelle <arnout@mind.be>: > > > >> 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. What does rpcbind use? ipv6 stuff? > 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. Musl does not implement RPC. Gnu Libc deprecated it for a while. > 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. When Rpc is activated it will be included in libc.a since 1.0.18... Arc external toolchain uses the old uclibc, where the combined libc isn't made. Should uclibc-ng drop rpc support? best regards Waldemar > 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 > ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-03-17 2017-03-18 16:33 ` Waldemar Brodkorb @ 2017-03-18 17:11 ` Arnout Vandecappelle 2017-03-18 19:46 ` Waldemar Brodkorb 0 siblings, 1 reply; 7+ messages in thread From: Arnout Vandecappelle @ 2017-03-18 17:11 UTC (permalink / raw) To: buildroot On 18-03-17 17:33, Waldemar Brodkorb wrote: > Hi, > >> Am 18.03.2017 um 17:19 schrieb Arnout Vandecappelle <arnout@mind.be>: >> >> >> >>> 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. > > What does rpcbind use? ipv6 stuff? I have no idea, I just see that rpcbind selects libtirpc. >> 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. > > Musl does not implement RPC. Gnu Libc deprecated it for a while. Hm, we still seem to enable RPC in glibc in Buildroot, and all our external toolchains except Codescape have it enabled as well. So the world doesn't seem to have caught on yet to that deprecation :-) > >> 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. > > When Rpc is activated it will be included in libc.a since 1.0.18... > > Arc external toolchain uses the old uclibc, where the combined libc isn't made. D'oh, silly me... So then I wonder, why don't we see this nfs-utils build failure on ARM? I just tested, and nfs-utils actually does succeed to build on arm-static. Hang on, microblaze has linuxthreads instead of NPTL... That's why it behaves differently. So, either this is fixed somehow in the linuxthreads implementation of uClibc, or we make libtirpc depend on !linuxthreads (nothreads is OK since the RPC stuff is pulled in by cancel.os - and anyway libtirpc depends on threads). > Should uclibc-ng drop rpc support? I don't think that that's needed. 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-03-17 2017-03-18 17:11 ` Arnout Vandecappelle @ 2017-03-18 19:46 ` Waldemar Brodkorb 0 siblings, 0 replies; 7+ messages in thread From: Waldemar Brodkorb @ 2017-03-18 19:46 UTC (permalink / raw) To: buildroot Hi, Arnout Vandecappelle wrote, > > > On 18-03-17 17:33, Waldemar Brodkorb wrote: > > Hi, > > > >> Am 18.03.2017 um 17:19 schrieb Arnout Vandecappelle <arnout@mind.be>: > >> > >> > >> > >>> 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. > > > > What does rpcbind use? ipv6 stuff? > > I have no idea, I just see that rpcbind selects libtirpc. > > > >> 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. > > > > Musl does not implement RPC. Gnu Libc deprecated it for a while. > > Hm, we still seem to enable RPC in glibc in Buildroot, and all our external > toolchains except Codescape have it enabled as well. So the world doesn't seem > to have caught on yet to that deprecation :-) > > > > >> 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. > > > > When Rpc is activated it will be included in libc.a since 1.0.18... > > > > Arc external toolchain uses the old uclibc, where the combined libc isn't made. > > D'oh, silly me... > > So then I wonder, why don't we see this nfs-utils build failure on ARM? I just > tested, and nfs-utils actually does succeed to build on arm-static. > > Hang on, microblaze has linuxthreads instead of NPTL... That's why it behaves > differently. > > So, either this is fixed somehow in the linuxthreads implementation of uClibc, > or we make libtirpc depend on !linuxthreads (nothreads is OK since the RPC stuff > is pulled in by cancel.os - and anyway libtirpc depends on threads). > > > Should uclibc-ng drop rpc support? > > I don't think that that's needed. Hmm. rpcbind latest release requires libtirpc. I am wondering if it is worth to keep an old ipv4 only rpc implementation intree if nobody use it? best regards Waldemar ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2017-03-18 19:46 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-03-18 7:28 [Buildroot] [autobuild.buildroot.net] Build results for 2017-03-17 Thomas Petazzoni 2017-03-18 15:15 ` Arnout Vandecappelle 2017-03-18 16:02 ` Waldemar Brodkorb 2017-03-18 16:19 ` Arnout Vandecappelle 2017-03-18 16:33 ` Waldemar Brodkorb 2017-03-18 17:11 ` Arnout Vandecappelle 2017-03-18 19:46 ` Waldemar Brodkorb
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.