| Message ID | 1410157964-8422-2-git-send-email-abrodkin@synopsys.com |
|---|---|
| State | Rejected |
| Headers | show |
Dear Alexey Brodkin, On Mon, 8 Sep 2014 10:32:43 +0400, Alexey Brodkin wrote: > Fixes: > http://autobuild.buildroot.net/results/6bb90d3f2b840a1faacf152a1d93a909a2dc98d3 > http://autobuild.buildroot.net/results/994a84d192848b90a70e28e5ebaa769701bcaec9 > > Following packages select "libtirpc", so adding dependency as well: > * argus > * conntrack-tools > * lmbench > * nfs-utils > * quota > * rpcbind > > Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> That's not that simple because you forget to update the comments: they should not be displayed if the architecture doesn't have the atomic intrinsics. And this is where things start to be really, really weird. > diff --git a/package/conntrack-tools/Config.in b/package/conntrack-tools/Config.in > index ec19d8e..36b12b7 100644 > --- a/package/conntrack-tools/Config.in > +++ b/package/conntrack-tools/Config.in > @@ -3,6 +3,7 @@ config BR2_PACKAGE_CONNTRACK_TOOLS > depends on BR2_INET_IPV6 > depends on BR2_LARGEFILE > depends on BR2_USE_MMU # fork() > + depends on BR2_ARCH_HAS_ATOMICS # libtirpc That's not correct: if the toolchain has native RPC support, we do not need libtirpc, so there is no need to depend on BR2_ARCH_HAS_ATOMICS in this case. I already tried to solve this thing, but it's much more complicated than just adding a bunch of "depends on". Thomas
Hi Thomas, On Mon, 2014-09-08 at 09:23 +0200, Thomas Petazzoni wrote: > Dear Alexey Brodkin, > > Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> > > That's not that simple because you forget to update the comments: they > should not be displayed if the architecture doesn't have the atomic > intrinsics. And this is where things start to be really, really weird. > > diff --git a/package/conntrack-tools/Config.in b/package/conntrack-tools/Config.in > > index ec19d8e..36b12b7 100644 > > --- a/package/conntrack-tools/Config.in > > +++ b/package/conntrack-tools/Config.in > > @@ -3,6 +3,7 @@ config BR2_PACKAGE_CONNTRACK_TOOLS > > depends on BR2_INET_IPV6 > > depends on BR2_LARGEFILE > > depends on BR2_USE_MMU # fork() > > + depends on BR2_ARCH_HAS_ATOMICS # libtirpc > > That's not correct: if the toolchain has native RPC support, we do not > need libtirpc, so there is no need to depend on BR2_ARCH_HAS_ATOMICS in > this case. > > I already tried to solve this thing, but it's much more complicated > than just adding a bunch of "depends on". So I assume there's no sense for me to try fixing comments, right? I mean if this won't work either or introduce new problems as you meant. Then what could be our next steps to accommodate possibility of existence/absence of atomic ops? This is especially important for ARC where these ops are optional. The simplest solution could be to enable BR2_ARCH_HAS_ATOMICS for ARC by default, but this will just attempt to escape from real problem. And as I saw from other autobuild results other architectures are affected like Blackfin for example. If this is that complicated we may try to discuss it in person on Buildroot summit in few weeks. -Alexey
Dear Alexey Brodkin, On Mon, 8 Sep 2014 09:23:02 +0000, Alexey Brodkin wrote: > > I already tried to solve this thing, but it's much more complicated > > than just adding a bunch of "depends on". > > So I assume there's no sense for me to try fixing comments, right? > I mean if this won't work either or introduce new problems as you meant. There is definitely some sense in fixing this stuff. I'm not sure yet on how to do this. I had some discussion with Thomas DS a week ago or so on IRC about this. > This is especially important for ARC where these ops are optional. > The simplest solution could be to enable BR2_ARCH_HAS_ATOMICS for ARC by > default, but this will just attempt to escape from real problem. > > And as I saw from other autobuild results other architectures are > affected like Blackfin for example. Yes, sure, we need to fix the problem. It's just not as simple as adding more "depends on", unfortunately :-( > If this is that complicated we may try to discuss it in person on > Buildroot summit in few weeks. Ah, you're planning on coming to the Buildroot meeting? If so, could you register to http://elinux.org/Buildroot:DeveloperDaysELCE2014, or confirm me that you are coming so that I can add your name to the list of participants? Thanks! Thomas
Hi Thomas, On Mon, 2014-09-08 at 11:27 +0200, Thomas Petazzoni wrote: > Dear Alexey Brodkin, > > On Mon, 8 Sep 2014 09:23:02 +0000, Alexey Brodkin wrote: > Ah, you're planning on coming to the Buildroot meeting? If so, could > you register to http://elinux.org/Buildroot:DeveloperDaysELCE2014, or > confirm me that you are coming so that I can add your name to the list > of participants? Do you mind to add another atomic ops discussion as another item to "Topics to discuss" during the event? -Alexey
Dear Alexey Brodkin, On Fri, 12 Sep 2014 13:12:03 +0000, Alexey Brodkin wrote: > > Ah, you're planning on coming to the Buildroot meeting? If so, could > > you register to http://elinux.org/Buildroot:DeveloperDaysELCE2014, or > > confirm me that you are coming so that I can add your name to the list > > of participants? > > Do you mind to add another atomic ops discussion as another item to > "Topics to discuss" during the event? I've added it. But to be honest, I hope to be able to make a proposal to solve the problem before the meeting. Thanks! Thomas
Hi Thomas, On Fri, 2014-09-12 at 15:25 +0200, Thomas Petazzoni wrote: > Dear Alexey Brodkin, > > On Fri, 12 Sep 2014 13:12:03 +0000, Alexey Brodkin wrote: > > > > Ah, you're planning on coming to the Buildroot meeting? If so, could > > > you register to http://elinux.org/Buildroot:DeveloperDaysELCE2014, or > > > confirm me that you are coming so that I can add your name to the list > > > of participants? > > > > Do you mind to add another atomic ops discussion as another item to > > "Topics to discuss" during the event? > > I've added it. But to be honest, I hope to be able to make a proposal > to solve the problem before the meeting. Good to know it! Please let me know if I may somehow help you with it. -Alexey
diff --git a/package/argus/Config.in b/package/argus/Config.in index 6d47734..2fab07a 100644 --- a/package/argus/Config.in +++ b/package/argus/Config.in @@ -1,6 +1,7 @@ config BR2_PACKAGE_ARGUS bool "argus" depends on BR2_INET_IPV6 + depends on BR2_ARCH_HAS_ATOMICS # libtirpc depends on BR2_TOOLCHAIN_HAS_THREADS depends on BR2_USE_MMU # fork() select BR2_PACKAGE_LIBPCAP diff --git a/package/conntrack-tools/Config.in b/package/conntrack-tools/Config.in index ec19d8e..36b12b7 100644 --- a/package/conntrack-tools/Config.in +++ b/package/conntrack-tools/Config.in @@ -3,6 +3,7 @@ config BR2_PACKAGE_CONNTRACK_TOOLS depends on BR2_INET_IPV6 depends on BR2_LARGEFILE depends on BR2_USE_MMU # fork() + depends on BR2_ARCH_HAS_ATOMICS # libtirpc depends on BR2_TOOLCHAIN_HAS_NATIVE_RPC || BR2_TOOLCHAIN_HAS_THREADS # libtirpc select BR2_PACKAGE_LIBNETFILTER_CONNTRACK select BR2_PACKAGE_LIBNETFILTER_CTHELPER diff --git a/package/libtirpc/Config.in b/package/libtirpc/Config.in index a8e6dd3..a5fe175 100644 --- a/package/libtirpc/Config.in +++ b/package/libtirpc/Config.in @@ -7,6 +7,7 @@ config BR2_PACKAGE_LIBTIRPC # used instead of libtirpc. depends on !BR2_TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_2012R2 depends on BR2_TOOLCHAIN_HAS_THREADS + depends on BR2_ARCH_HAS_ATOMICS help Libtirpc is a port of Sun's Transport-Independent RPC library to Linux. diff --git a/package/lmbench/Config.in b/package/lmbench/Config.in index c4ea522..5b88d62 100644 --- a/package/lmbench/Config.in +++ b/package/lmbench/Config.in @@ -1,5 +1,6 @@ config BR2_PACKAGE_LMBENCH bool "lmbench" + depends on BR2_ARCH_HAS_ATOMICS # libtirpc depends on BR2_TOOLCHAIN_HAS_NATIVE_RPC || BR2_TOOLCHAIN_HAS_THREADS # libtirpc select BR2_PACKAGE_LIBTIRPC if !BR2_TOOLCHAIN_HAS_NATIVE_RPC depends on BR2_USE_MMU # fork() diff --git a/package/nfs-utils/Config.in b/package/nfs-utils/Config.in index dff5150..3168333 100644 --- a/package/nfs-utils/Config.in +++ b/package/nfs-utils/Config.in @@ -5,6 +5,7 @@ comment "nfs-utils needs a toolchain w/ largefile, threads" config BR2_PACKAGE_NFS_UTILS bool "nfs-utils" + depends on BR2_ARCH_HAS_ATOMICS # libtirpc depends on BR2_TOOLCHAIN_HAS_NATIVE_RPC || BR2_TOOLCHAIN_HAS_THREADS # libtirpc select BR2_PACKAGE_LIBTIRPC if !BR2_TOOLCHAIN_HAS_NATIVE_RPC depends on BR2_LARGEFILE diff --git a/package/quota/Config.in b/package/quota/Config.in index 69f03af..cceb2ab 100644 --- a/package/quota/Config.in +++ b/package/quota/Config.in @@ -4,6 +4,7 @@ config BR2_PACKAGE_QUOTA depends on BR2_USE_WCHAR depends on BR2_USE_MMU # fork() depends on !(BR2_microblazeel || BR2_microblazebe) # util-linux + depends on BR2_ARCH_HAS_ATOMICS # libtirpc depends on BR2_TOOLCHAIN_HAS_NATIVE_RPC || BR2_TOOLCHAIN_HAS_THREADS # libtirpc select BR2_PACKAGE_UTIL_LINUX select BR2_PACKAGE_UTIL_LINUX_BINARIES diff --git a/package/rpcbind/Config.in b/package/rpcbind/Config.in index 2a79bdc..bc658d6 100644 --- a/package/rpcbind/Config.in +++ b/package/rpcbind/Config.in @@ -2,6 +2,7 @@ config BR2_PACKAGE_RPCBIND bool "rpcbind" # We really need libtirpc and can't work with the native RPC # implementation of toolchains. + depends on BR2_ARCH_HAS_ATOMICS # libtirpc depends on BR2_TOOLCHAIN_HAS_THREADS # libtirpc select BR2_PACKAGE_LIBTIRPC # uClibc toolchains provided by ADI don't have AI_ADDRCONFIG
Fixes: http://autobuild.buildroot.net/results/6bb90d3f2b840a1faacf152a1d93a909a2dc98d3 http://autobuild.buildroot.net/results/994a84d192848b90a70e28e5ebaa769701bcaec9 Following packages select "libtirpc", so adding dependency as well: * argus * conntrack-tools * lmbench * nfs-utils * quota * rpcbind Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Anton Kolesov <akolesov@synopsys.com> Cc: Gustavo Zacarias <gustavo@zacarias.com.ar> Cc: Peter Korsgaard <peter@korsgaard.com> CC: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> --- package/argus/Config.in | 1 + package/conntrack-tools/Config.in | 1 + package/libtirpc/Config.in | 1 + package/lmbench/Config.in | 1 + package/nfs-utils/Config.in | 1 + package/quota/Config.in | 1 + package/rpcbind/Config.in | 1 + 7 files changed, 7 insertions(+)