[PATCH] Fix build if __GLIBC_PREREQ is not defined
Jörg Krause
joerg.krause at embedded.rocks
Thu Mar 8 16:35:51 UTC 2018
Hi Guillem,
On Thu, 2018-03-08 at 02:21 +0100, Guillem Jover wrote:
> Hi!
>
> On Wed, 2018-03-07 at 21:48:39 +0100, Jörg Krause wrote:
> > On Wed, 2018-03-07 at 21:13 +0100, Jörg Krause wrote:
> > > On Fri, 2018-03-02 at 08:03 +0100, Jörg Krause wrote:
> > > > __GLIBC_PREREQ is specific to glibc so it should be checked if it is
> > > > defined or not.
> > > >
> > > > Fixes build error with musl:
> > > > '''
> > > > ../include/bsd/stdlib.h:70:66: error: missing binary operator before token "("
> > > > #if defined(_GNU_SOURCE) && defined(__GLIBC__) && !__GLIBC_PREREQ(2, 26)
> > > I've noticed that this patch allows building with musl, but produces
> > > warnings because of implicit function declarations.
> > >
> > > An improved version of the patch could be for example:
> > >
> > > '''
> > > #if defined(__GLIBC__) && defined(__GLIBC_PREREQ)
> > > #if __GLIBC_PREREQ(2, 25)
> > > #define HAVE_EXPLICIT_BZERO
> > > #endif
> > > #endif
> > >
> > > __BEGIN_DECLS
> > > [...]
> > >
> > > #if defined(_GNU_SOURCE) && !defined(HAVE_EXPLICIT_BZERO)
> > > void explicit_bzero(void *buf, size_t len);
> > > #endif
> > > __END_DECLS
> > > '''AC_CHECK_FUNCS
> > >
> > > Would do you think?
>
> When I saw your initial patch started checking the existing code and
> noticed that it was just broken. So insted I ended up with the
> attachment. Please let me know if that works for you, and I'll include
> it in my next push.
There is something wrong with parentheses:
+#if !defined(__GLIBC__) || \
+ (defined(__GLIBC__) && (!__GLIBC_PREREQ(2, 26) || !defined(_GNU_SOURCE))
^
|
The second misses an closing round parenthesis.
> > At second thought adding explicit_bzero and reallocarray to
> > AC_CHECK_FUNCS is much more convenient, right?
>
> The problem is that these are public headers, where we cannot (or
> should not) make use of build time detection via config.h, because
> those are to be used on the installed system where the libc version
> might be different to the use to compile the library.
I see!
Best regards,
Jörg Krause
More information about the libbsd
mailing list