Hi Waldemar, On Fri, 2016-06-03 at 17:16 +0200, Waldemar Brodkorb wrote: > Hi Alexey, > Alexey Brodkin wrote, > > > > > Hi Waldemar, > > > > On Fri, 2016-06-03 at 04:23 +0200, Waldemar Brodkorb wrote: > > > > > > uClibc-ng tries to be compatible with GNU libc and defines > > > __GLIBC__ and pretend to be version 2.2. > > > We once changed it to 2.10, but then some hard to fix problems > > > in different software packages (gcc) occured. > > > It would be better if we disable the special GNU libc checks > > > for uClibc-ng here. uClibc-ng implements the required scanf > > > functionality. > > > > > > Signed-off-by: Waldemar Brodkorb <w...@uclibc-ng.org> > > > --- > > > configure.ac | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/configure.ac b/configure.ac > > > index f36b18c..4661c0d 100644 > > > --- a/configure.ac > > > +++ b/configure.ac > > > @@ -581,7 +581,7 @@ AC_CACHE_VAL([scanf_cv_alloc_modifier], > > > #include <stdio.h> > > > #include <unistd.h> > > > > > > - #ifdef __GLIBC__ > > > + #if defined(__GLIBC__) && !defined(__UCLIBC__) > > > > > > #if !(__GLIBC_PREREQ(2, 7)) > > > #error %m is not available > > Even though this is a very minor and clean change I don't like this > > approach. We're again implicitly assume something. > > > > IMHO much better approach would be to include a compile test for > > small source that uses scanf() with "%as"/"%ms". > > > > That way we may remove all dependencies on either GLIBC/UCLIBC/MUSL etc. > Just for completeness, I saw your other mail already. > Musl has no problem with this code, because it is util-linux > fallback code for old GNU libc. Unfortunately it matches the > pretended version from uClibc-ng. So I think it is the right > solution, if the fallback code will not be removed.
Thanks for explanation. -Alexey _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
