* [Buildroot] [PATCH] ipkg: needs MMU
@ 2016-07-26 4:00 Baruch Siach
2016-07-26 7:59 ` Thomas Petazzoni
0 siblings, 1 reply; 10+ messages in thread
From: Baruch Siach @ 2016-07-26 4:00 UTC (permalink / raw
To: buildroot
Fixes:
http://autobuild.buildroot.net/results/6cf/6cf75e08795d9ab194ce4e882c0f4858bad979c3/
http://autobuild.buildroot.net/results/964/964d8f694bc7d05b35411eabfbadf40bbf6337ae/
http://autobuild.buildroot.net/results/0f2/0f2cddf89af3ad4330556acd04ab6cb080370e24/
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
package/ipkg/Config.in | 1 +
1 file changed, 1 insertion(+)
diff --git a/package/ipkg/Config.in b/package/ipkg/Config.in
index 4b2078d9cd70..d93e1d17b3dd 100644
--- a/package/ipkg/Config.in
+++ b/package/ipkg/Config.in
@@ -1,5 +1,6 @@
config BR2_PACKAGE_IPKG
bool "ipkg"
+ depends on BR2_USE_MMU # fork()
help
The Itsy Package Installer from handhelds.org
--
2.8.1
^ permalink raw reply related [flat|nested] 10+ messages in thread
* [Buildroot] [PATCH] ipkg: needs MMU
2016-07-26 4:00 [Buildroot] [PATCH] ipkg: needs MMU Baruch Siach
@ 2016-07-26 7:59 ` Thomas Petazzoni
2016-07-26 8:01 ` Thomas Petazzoni
0 siblings, 1 reply; 10+ messages in thread
From: Thomas Petazzoni @ 2016-07-26 7:59 UTC (permalink / raw
To: buildroot
Hello,
On Tue, 26 Jul 2016 07:00:37 +0300, Baruch Siach wrote:
> Fixes:
> http://autobuild.buildroot.net/results/6cf/6cf75e08795d9ab194ce4e882c0f4858bad979c3/
> http://autobuild.buildroot.net/results/964/964d8f694bc7d05b35411eabfbadf40bbf6337ae/
> http://autobuild.buildroot.net/results/0f2/0f2cddf89af3ad4330556acd04ab6cb080370e24/
>
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> ---
> package/ipkg/Config.in | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/package/ipkg/Config.in b/package/ipkg/Config.in
> index 4b2078d9cd70..d93e1d17b3dd 100644
> --- a/package/ipkg/Config.in
> +++ b/package/ipkg/Config.in
> @@ -1,5 +1,6 @@
> config BR2_PACKAGE_IPKG
> bool "ipkg"
> + depends on BR2_USE_MMU # fork()
I think this needs more investigation, because:
BR2_bfin=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_INIT_NONE=y
# BR2_PACKAGE_BUSYBOX is not set
BR2_PACKAGE_IPKG=y
# BR2_TARGET_ROOTFS_TAR is not set
which is a noMMU configuration, is able to build ipkg just fine.
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Buildroot] [PATCH] ipkg: needs MMU
2016-07-26 7:59 ` Thomas Petazzoni
@ 2016-07-26 8:01 ` Thomas Petazzoni
2016-07-26 11:15 ` Baruch Siach
0 siblings, 1 reply; 10+ messages in thread
From: Thomas Petazzoni @ 2016-07-26 8:01 UTC (permalink / raw
To: buildroot
Hello,
Sorry, last e-mail sent mistakenly.
On Tue, 26 Jul 2016 09:59:29 +0200, Thomas Petazzoni wrote:
> I think this needs more investigation, because:
>
> BR2_bfin=y
> BR2_TOOLCHAIN_EXTERNAL=y
> BR2_INIT_NONE=y
> # BR2_PACKAGE_BUSYBOX is not set
> BR2_PACKAGE_IPKG=y
> # BR2_TARGET_ROOTFS_TAR is not set
>
> which is a noMMU configuration, is able to build ipkg just fine.
I was indeed a bit surprised to see this patch: we have been having
Blackfin configurations for a long time in the autobuilders, and we
never had to add a BR2_USE_MMU dependency on this package.
So I believe there's something a bit more subtle going on here.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Buildroot] [PATCH] ipkg: needs MMU
2016-07-26 8:01 ` Thomas Petazzoni
@ 2016-07-26 11:15 ` Baruch Siach
2016-07-26 11:48 ` Thomas Petazzoni
0 siblings, 1 reply; 10+ messages in thread
From: Baruch Siach @ 2016-07-26 11:15 UTC (permalink / raw
To: buildroot
Hi Thomas,
On Tue, Jul 26, 2016 at 10:01:01AM +0200, Thomas Petazzoni wrote:
> On Tue, 26 Jul 2016 09:59:29 +0200, Thomas Petazzoni wrote:
> > I think this needs more investigation, because:
> >
> > BR2_bfin=y
> > BR2_TOOLCHAIN_EXTERNAL=y
> > BR2_INIT_NONE=y
> > # BR2_PACKAGE_BUSYBOX is not set
> > BR2_PACKAGE_IPKG=y
> > # BR2_TARGET_ROOTFS_TAR is not set
> >
> > which is a noMMU configuration, is able to build ipkg just fine.
>
> I was indeed a bit surprised to see this patch: we have been having
> Blackfin configurations for a long time in the autobuilders, and we
> never had to add a BR2_USE_MMU dependency on this package.
>
> So I believe there's something a bit more subtle going on here.
Right. It's this code from libbb/libbb.h:
/* Cope with mmu-less systems somewhat gracefully */
#if defined(__UCLIBC__) && !defined(__ARCH_HAS_MMU__)
#define fork vfork
#endif
This breaks musl that does not define __UCLIBC__. I posted an updated patch to
uses HAVE_FORK instead.
Is there anyone actually using this package anyway? Even its homepage is not
accessible here (handhelds.org does not resolve).
Thanks for reviewing,
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Buildroot] [PATCH] ipkg: needs MMU
2016-07-26 11:15 ` Baruch Siach
@ 2016-07-26 11:48 ` Thomas Petazzoni
2016-07-26 12:14 ` Baruch Siach
0 siblings, 1 reply; 10+ messages in thread
From: Thomas Petazzoni @ 2016-07-26 11:48 UTC (permalink / raw
To: buildroot
Hello,
On Tue, 26 Jul 2016 14:15:57 +0300, Baruch Siach wrote:
> Right. It's this code from libbb/libbb.h:
>
> /* Cope with mmu-less systems somewhat gracefully */
> #if defined(__UCLIBC__) && !defined(__ARCH_HAS_MMU__)
> #define fork vfork
> #endif
>
> This breaks musl that does not define __UCLIBC__. I posted an updated patch to
> uses HAVE_FORK instead.
We don't use musl on any noMMU platform today, so this certainly cannot
explain failures like:
http://autobuild.buildroot.net/results/6cf/6cf75e08795d9ab194ce4e882c0f4858bad979c3/
(which was the first one mentioned in your commit log), since this
failure happens with uClibc.
Looking at http://autobuild.buildroot.net/?reason=ipkg-0.99.163, I see
(looking only at the failures since the beginning of 2016) :
* Numerous failures on ARM noMMU (uClibc)
* Two failures on m68k noMMU (uClibc)
* An old failure on i686 due to download issue
i.e, none of the failures are caused by a musl-related build.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Buildroot] [PATCH] ipkg: needs MMU
2016-07-26 11:48 ` Thomas Petazzoni
@ 2016-07-26 12:14 ` Baruch Siach
2016-07-26 12:52 ` Thomas Petazzoni
2016-07-26 18:10 ` Khem Raj
0 siblings, 2 replies; 10+ messages in thread
From: Baruch Siach @ 2016-07-26 12:14 UTC (permalink / raw
To: buildroot
Hi Thomas,
On Tue, Jul 26, 2016 at 01:48:01PM +0200, Thomas Petazzoni wrote:
> On Tue, 26 Jul 2016 14:15:57 +0300, Baruch Siach wrote:
> > Right. It's this code from libbb/libbb.h:
> >
> > /* Cope with mmu-less systems somewhat gracefully */
> > #if defined(__UCLIBC__) && !defined(__ARCH_HAS_MMU__)
> > #define fork vfork
> > #endif
> >
> > This breaks musl that does not define __UCLIBC__. I posted an updated patch to
> > uses HAVE_FORK instead.
>
> We don't use musl on any noMMU platform today, so this certainly cannot
> explain failures like:
>
> http://autobuild.buildroot.net/results/6cf/6cf75e08795d9ab194ce4e882c0f4858bad979c3/
>
> (which was the first one mentioned in your commit log), since this
> failure happens with uClibc.
>
> Looking at http://autobuild.buildroot.net/?reason=ipkg-0.99.163, I see
> (looking only at the failures since the beginning of 2016) :
>
> * Numerous failures on ARM noMMU (uClibc)
> * Two failures on m68k noMMU (uClibc)
> * An old failure on i686 due to download issue
>
> i.e, none of the failures are caused by a musl-related build.
You are right of course, forgive my sloppiness. To be correct for uClibc the
code should test for __ARCH_USE_MMU__ instead of __ARCH_HAS_MMU__. But testing
HAVE_FORK is better, I thing, since it also covers other hypothetical MMU-less
C libraries.
I'll resend the patch with a correct description.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Buildroot] [PATCH] ipkg: needs MMU
2016-07-26 12:14 ` Baruch Siach
@ 2016-07-26 12:52 ` Thomas Petazzoni
2016-07-26 15:08 ` Baruch Siach
2016-07-26 18:10 ` Khem Raj
1 sibling, 1 reply; 10+ messages in thread
From: Thomas Petazzoni @ 2016-07-26 12:52 UTC (permalink / raw
To: buildroot
Hello,
On Tue, 26 Jul 2016 15:14:29 +0300, Baruch Siach wrote:
> You are right of course, forgive my sloppiness. To be correct for uClibc the
> code should test for __ARCH_USE_MMU__ instead of __ARCH_HAS_MMU__. But testing
> HAVE_FORK is better, I thing, since it also covers other hypothetical MMU-less
> C libraries.
Using HAVE_FORK indeed seems better. However, can you verify that it
actually works for MMU-capable platforms?
What worries me is that the code in libbb/ originally comes from
Busybox, which doesn't use autoconf. HAVE_FORK is a #define value
defined by ipkg's autoconf configure script, in config.h, and I'm not
sure if the libbb/ code includes config.h.
So, please make sure that HAVE_FORK is really taken into account when
building on MMU-capable platforms by adding some #error in the #if
defined(HAVE_FORK) test in the libbb code that you're changing.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Buildroot] [PATCH] ipkg: needs MMU
2016-07-26 12:52 ` Thomas Petazzoni
@ 2016-07-26 15:08 ` Baruch Siach
2016-07-26 15:19 ` Thomas Petazzoni
0 siblings, 1 reply; 10+ messages in thread
From: Baruch Siach @ 2016-07-26 15:08 UTC (permalink / raw
To: buildroot
Hi Thomas,
On Tue, Jul 26, 2016 at 02:52:48PM +0200, Thomas Petazzoni wrote:
> On Tue, 26 Jul 2016 15:14:29 +0300, Baruch Siach wrote:
> > You are right of course, forgive my sloppiness. To be correct for uClibc
> > the code should test for __ARCH_USE_MMU__ instead of __ARCH_HAS_MMU__. But
> > testing HAVE_FORK is better, I thing, since it also covers other
> > hypothetical MMU-less C libraries.
>
> Using HAVE_FORK indeed seems better. However, can you verify that it
> actually works for MMU-capable platforms?
>
> What worries me is that the code in libbb/ originally comes from
> Busybox, which doesn't use autoconf. HAVE_FORK is a #define value
> defined by ipkg's autoconf configure script, in config.h, and I'm not
> sure if the libbb/ code includes config.h.
>
> So, please make sure that HAVE_FORK is really taken into account when
> building on MMU-capable platforms by adding some #error in the #if
> defined(HAVE_FORK) test in the libbb code that you're changing.
I verified that config.h macros are defined in libbb.h before posting the last
patch, by using another defined macros. I repeated this test as you suggested,
with HAVE_FORK and the current br-arm-full.config, just to be sure. The #error
triggers as expected in both tests.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Buildroot] [PATCH] ipkg: needs MMU
2016-07-26 15:08 ` Baruch Siach
@ 2016-07-26 15:19 ` Thomas Petazzoni
0 siblings, 0 replies; 10+ messages in thread
From: Thomas Petazzoni @ 2016-07-26 15:19 UTC (permalink / raw
To: buildroot
Hello,
On Tue, 26 Jul 2016 18:08:54 +0300, Baruch Siach wrote:
> I verified that config.h macros are defined in libbb.h before posting the last
> patch, by using another defined macros. I repeated this test as you suggested,
> with HAVE_FORK and the current br-arm-full.config, just to be sure. The #error
> triggers as expected in both tests.
Excellent, thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Buildroot] [PATCH] ipkg: needs MMU
2016-07-26 12:14 ` Baruch Siach
2016-07-26 12:52 ` Thomas Petazzoni
@ 2016-07-26 18:10 ` Khem Raj
1 sibling, 0 replies; 10+ messages in thread
From: Khem Raj @ 2016-07-26 18:10 UTC (permalink / raw
To: buildroot
> On Jul 26, 2016, at 5:14 AM, Baruch Siach <baruch@tkos.co.il> wrote:
>
> Hi Thomas,
>
> On Tue, Jul 26, 2016 at 01:48:01PM +0200, Thomas Petazzoni wrote:
>> On Tue, 26 Jul 2016 14:15:57 +0300, Baruch Siach wrote:
>>> Right. It's this code from libbb/libbb.h:
>>>
>>> /* Cope with mmu-less systems somewhat gracefully */
>>> #if defined(__UCLIBC__) && !defined(__ARCH_HAS_MMU__)
>>> #define fork vfork
>>> #endif
>>>
>>> This breaks musl that does not define __UCLIBC__. I posted an updated patch to
>>> uses HAVE_FORK instead.
>>
>> We don't use musl on any noMMU platform today,
SH2 fdpic is available in musl, so in theory you can start :)
>> so this certainly cannot
>> explain failures like:
>>
>> http://autobuild.buildroot.net/results/6cf/6cf75e08795d9ab194ce4e882c0f4858bad979c3/
>>
>> (which was the first one mentioned in your commit log), since this
>> failure happens with uClibc.
>>
>> Looking at http://autobuild.buildroot.net/?reason=ipkg-0.99.163, I see
>> (looking only at the failures since the beginning of 2016) :
>>
>> * Numerous failures on ARM noMMU (uClibc)
>> * Two failures on m68k noMMU (uClibc)
>> * An old failure on i686 due to download issue
>>
>> i.e, none of the failures are caused by a musl-related build.
>
> You are right of course, forgive my sloppiness. To be correct for uClibc the
> code should test for __ARCH_USE_MMU__ instead of __ARCH_HAS_MMU__. But testing
> HAVE_FORK is better, I thing, since it also covers other hypothetical MMU-less
> C libraries.
ARCH_USE_MMU seems to be sufficient unless there is any other kind of memory
management system that can redefine fork behavior.
is fork the only difference when it comes to nommu, I guess not. So why create an
extra check just for fork.
>
> I'll resend the patch with a correct description.
>
> baruch
>
> --
> http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
> =}------------------------------------------------ooO--U--Ooo------------{=
> - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20160726/f77e1d15/attachment.asc>
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2016-07-26 18:10 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-07-26 4:00 [Buildroot] [PATCH] ipkg: needs MMU Baruch Siach
2016-07-26 7:59 ` Thomas Petazzoni
2016-07-26 8:01 ` Thomas Petazzoni
2016-07-26 11:15 ` Baruch Siach
2016-07-26 11:48 ` Thomas Petazzoni
2016-07-26 12:14 ` Baruch Siach
2016-07-26 12:52 ` Thomas Petazzoni
2016-07-26 15:08 ` Baruch Siach
2016-07-26 15:19 ` Thomas Petazzoni
2016-07-26 18:10 ` Khem Raj
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.