3 Jun
2016
3 Jun
'16
3:16 p.m.
Hi Alexey,
Alexey Brodkin wrote,
Hi Waldemar,
On Fri, 2016-06-03 at 04:23 +0200, Waldemar Brodkorb wrote:
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.
best regards
Waldemar
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 <wbx(a)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.