All of lore.kernel.org
 help / color / mirror / Atom feed
* [yocto][meta-gplv2][PATCH 2/2 v2] diffutils: musl has working malloc() and realloc()
       [not found] <15E7F1D320E9D777.2841@lists.yoctoproject.org>
@ 2020-01-08 16:15 ` Andr? Draszik
  2020-01-08 16:18   ` Ross Burton
  0 siblings, 1 reply; 6+ messages in thread
From: Andr? Draszik @ 2020-01-08 16:15 UTC (permalink / raw)
  To: yocto

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


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [yocto][meta-gplv2][PATCH 2/2 v2] diffutils: musl has working malloc() and realloc()
  2020-01-08 16:15 ` [yocto][meta-gplv2][PATCH 2/2 v2] diffutils: musl has working malloc() and realloc() Andr? Draszik
@ 2020-01-08 16:18   ` Ross Burton
  2020-01-08 16:52     ` Andr? Draszik
  2020-01-08 21:10     ` Andr? Draszik
  0 siblings, 2 replies; 6+ messages in thread
From: Ross Burton @ 2020-01-08 16:18 UTC (permalink / raw)
  To: Andr? Draszik, yocto

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [yocto][meta-gplv2][PATCH 2/2 v2] diffutils: musl has working malloc() and realloc()
  2020-01-08 16:18   ` Ross Burton
@ 2020-01-08 16:52     ` Andr? Draszik
  2020-01-08 18:04       ` Adrian Bunk
  2020-01-08 21:10     ` Andr? Draszik
  1 sibling, 1 reply; 6+ messages in thread
From: Andr? Draszik @ 2020-01-08 16:52 UTC (permalink / raw)
  To: yocto

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'



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [yocto][meta-gplv2][PATCH 2/2 v2] diffutils: musl has working malloc() and realloc()
  2020-01-08 16:52     ` Andr? Draszik
@ 2020-01-08 18:04       ` Adrian Bunk
  2020-01-08 21:11         ` Andr? Draszik
  0 siblings, 1 reply; 6+ messages in thread
From: Adrian Bunk @ 2020-01-08 18:04 UTC (permalink / raw)
  To: Andr? Draszik; +Cc: yocto

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [yocto][meta-gplv2][PATCH 2/2 v2] diffutils: musl has working malloc() and realloc()
  2020-01-08 16:18   ` Ross Burton
  2020-01-08 16:52     ` Andr? Draszik
@ 2020-01-08 21:10     ` Andr? Draszik
  1 sibling, 0 replies; 6+ messages in thread
From: Andr? Draszik @ 2020-01-08 21:10 UTC (permalink / raw)
  To: yocto

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'



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [yocto][meta-gplv2][PATCH 2/2 v2] diffutils: musl has working malloc() and realloc()
  2020-01-08 18:04       ` Adrian Bunk
@ 2020-01-08 21:11         ` Andr? Draszik
  0 siblings, 0 replies; 6+ messages in thread
From: Andr? Draszik @ 2020-01-08 21:11 UTC (permalink / raw)
  To: yocto

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.



^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2020-01-08 21:11 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <15E7F1D320E9D777.2841@lists.yoctoproject.org>
2020-01-08 16:15 ` [yocto][meta-gplv2][PATCH 2/2 v2] diffutils: musl has working malloc() and realloc() Andr? Draszik
2020-01-08 16:18   ` Ross Burton
2020-01-08 16:52     ` Andr? Draszik
2020-01-08 18:04       ` Adrian Bunk
2020-01-08 21:11         ` Andr? Draszik
2020-01-08 21:10     ` Andr? Draszik

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.