* [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.