[yocto][meta-gplv2][PATCH 2/2 v2] diffutils: musl has working malloc() and realloc()

[yocto][meta-gplv2][PATCH 2/2 v2] diffutils: musl has working malloc() and realloc()

[Andr? Draszik]

diffutils tries to run a test program to determine if
malloc() and realloc() work, i.e. whether they fail if
given 0 for size. running a test program doesn't work
when cross-compiling, so it defaults to assuming non-
working malloc() / realloc()

Given they work correctly in musl, we can specify the
test-result, and avoid having to use diffutil's
replacement functions.

Signed-off-by: André Draszik <git@andred.net>

---
v2:
* switch to CACHED_CONFIGUREVARS instead of EXTRA_OECONF
---
 recipes-extended/diffutils/diffutils_2.8.1.bb | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/recipes-extended/diffutils/diffutils_2.8.1.bb b/recipes-extended/diffutils/diffutils_2.8.1.bb
index 4aad28f..680911b 100644
--- a/recipes-extended/diffutils/diffutils_2.8.1.bb
+++ b/recipes-extended/diffutils/diffutils_2.8.1.bb
@@ -16,6 +16,11 @@ SRC_URI = "${GNU_MIRROR}/diffutils/diffutils-${PV}.tar.gz \
 SRC_URI[md5sum] = "71f9c5ae19b60608f6c7f162da86a428"
 SRC_URI[sha256sum] = "c5001748b069224dd98bf1bb9ee877321c7de8b332c8aad5af3e2a7372d23f5a"
 
+CACHED_CONFIGUREVARS_libc-musl = "\
+    jm_cv_func_working_malloc=yes \
+    jm_cv_func_working_realloc=yes \
+"
+
 do_configure_prepend () {
 	chmod u+w ${S}/po/Makefile.in.in
 }
-- 
2.23.0.rc1

Re: [yocto][meta-gplv2][PATCH 2/2 v2] diffutils: musl has working malloc() and realloc()

[Ross Burton]

On 08/01/2020 16:15, Andr? Draszik wrote:
> +CACHED_CONFIGUREVARS_libc-musl = "\
> +    jm_cv_func_working_malloc=yes \
> +    jm_cv_func_working_realloc=yes \
> +"

Why is this musl-specific?  Does the configure explicitly detect glibc 
and know it's good, or should we do this for glibc too?

Ross

Re: [yocto][meta-gplv2][PATCH 2/2 v2] diffutils: musl has working malloc() and realloc()

[Andr? Draszik]

On Wed, 2020-01-08 at 16:18 +0000, Ross Burton wrote:
> On 08/01/2020 16:15, Andr? Draszik wrote:
> > +CACHED_CONFIGUREVARS_libc-musl = "\
> > +    jm_cv_func_working_malloc=yes \
> > +    jm_cv_func_working_realloc=yes \
> > +"
> 
> Why is this musl-specific?  Does the configure explicitly detect glibc 
> and know it's good, or should we do this for glibc too?

That's musl specific, because it's a property of the C-library in use.

E.g. somebody could be using this with an outdated vendor(?) toolchain
using an old glibc which could behave incorrectly...


Cheers,
Andre'

Re: [yocto][meta-gplv2][PATCH 2/2 v2] diffutils: musl has working malloc() and realloc()

[Adrian Bunk]

On Wed, Jan 08, 2020 at 04:52:36PM +0000, Andr? Draszik wrote:
> On Wed, 2020-01-08 at 16:18 +0000, Ross Burton wrote:
> > On 08/01/2020 16:15, Andr? Draszik wrote:
> > > +CACHED_CONFIGUREVARS_libc-musl = "\
> > > +    jm_cv_func_working_malloc=yes \
> > > +    jm_cv_func_working_realloc=yes \
> > > +"
> > 
> > Why is this musl-specific?  Does the configure explicitly detect glibc 
> > and know it's good, or should we do this for glibc too?
> 
> That's musl specific, because it's a property of the C-library in use.
> 
> E.g. somebody could be using this with an outdated vendor(?) toolchain
> using an old glibc which could behave incorrectly...
>...

The jm_cv_func_working_malloc test is:
    main ()
    {
      exit (malloc (0) ? 0 : 1);
    }

The C standard says that this is implementation defined,
both results are permitted.

glibc has the same behaviour forever,
musl switched to the glibc behaviour a few years ago.

> Cheers,
> Andre'

cu
Adrian

Re: [yocto][meta-gplv2][PATCH 2/2 v2] diffutils: musl has working malloc() and realloc()

[Andr? Draszik]

On Wed, 2020-01-08 at 20:04 +0200, Adrian Bunk wrote:
> On Wed, Jan 08, 2020 at 04:52:36PM +0000, Andr? Draszik wrote:
> > On Wed, 2020-01-08 at 16:18 +0000, Ross Burton wrote:
> > > On 08/01/2020 16:15, Andr? Draszik wrote:
> > > > +CACHED_CONFIGUREVARS_libc-musl = "\
> > > > +    jm_cv_func_working_malloc=yes \
> > > > +    jm_cv_func_working_realloc=yes \
> > > > +"
> > > 
> > > Why is this musl-specific?  Does the configure explicitly detect glibc 
> > > and know it's good, or should we do this for glibc too?
> > 
> > That's musl specific, because it's a property of the C-library in use.
> > 
> > E.g. somebody could be using this with an outdated vendor(?) toolchain
> > using an old glibc which could behave incorrectly...
> > ...
> 
> The jm_cv_func_working_malloc test is:
>     main ()
>     {
>       exit (malloc (0) ? 0 : 1);
>     }
> 
> The C standard says that this is implementation defined,
> both results are permitted.
> 
> glibc has the same behaviour forever,
> musl switched to the glibc behaviour a few years ago.

Thanks for the reminder. Final note, Back in the days, uClibc had
a compile time option to select one behaviour or the other.


Cheers,
A.

Re: [yocto][meta-gplv2][PATCH 2/2 v2] diffutils: musl has working malloc() and realloc()

[Andr? Draszik]

On Wed, 2020-01-08 at 16:18 +0000, Ross Burton wrote:
> On 08/01/2020 16:15, Andr? Draszik wrote:
> > +CACHED_CONFIGUREVARS_libc-musl = "\
> > +    jm_cv_func_working_malloc=yes \
> > +    jm_cv_func_working_realloc=yes \
> > +"
> 
> Why is this musl-specific?  Does the configure explicitly detect glibc 
> and know it's good, or should we do this for glibc too?

Sorry, I was too quick replying here... It's simply defaulting to no
because of cross-compilation, no matter what libc is in use.

I wanted to be conservative, but Adrian reminded me of actual issue
here...

Cheers,
Andre'