Setting up libaes_siv

Daniel Franke dfoxfranke at gmail.com
Fri Feb 15 22:32:49 UTC 2019


Hal, try putting

#define _ANSI_SOURCE 1
#define _ISOC99_SOURCE 1

at the very top of aes_siv.c and let me know if that fixes the build error.

Looks like the way <machine/bswap.h> is getting in is via
<sys/endian.h> via <sys/types.h> via <stdlib.h> via
<openssl/crypto.h>. But <stdlib.h> guards it with

#if defined(_NETBSD_SOURCE)
#include <sys/types.h> /* for quad_t, etc. */
#endif

while <sys/featuretest.h> has

#if !defined(_ANSI_SOURCE) && !defined(_POSIX_C_SOURCE) && \
!defined(_XOPEN_SOURCE) && !defined(_NETBSD_SOURCE)
#define _NETBSD_SOURCE 1
#endif

so I think defining _ANSI_SOURCE will suppress definition of
_NETBSD_SOURCE which will prevent the namespace pollution. If this
works for you I'll commit the change.

On Fri, Feb 15, 2019 at 7:49 AM Daniel Franke <dfoxfranke at gmail.com> wrote:
>
> It's exactly like I suspected: a system header is #defining bswap64 as
> a macro, causing a syntax error in my local definition. This is a
> upstream bug twice over. First, nothing should be giving you
> <machine/bswap.h> if you don't ask for it. Second, the manpage clearly
> states that bswap64 is a function, so it's unacceptable to implement
> it as a macro.
>
> The first bug might be either NetBSD or OpenSSL's fault, I need to
> figure out which. The second one is clearly NetBSD's fault. I'll deal
> with the OpenSSL fix if a fix is needed. I'll need you to do the
> NetBSD reporting since I don't have a NetBSD system and won't be able
> to answer any follow-up questions if I file the ticket myself. For the
> meantime, I'll probably have to work around the issue by renaming that
> function in libaes_siv.
>
> On Thu, Feb 14, 2019 at 11:33 PM Daniel Franke <dfoxfranke at gmail.com> wrote:
> >
> > This looks like namespace pollution of some kind -- perhaps one of
> > NetBSD's standard C headers defining a bswap64 macro that conflicts
> > with my definition. Can you send me what aes_siv.c looks like on your
> > system after preprocessing?
> >
> > I'm not going to support CMake 2, but CentOS has CMake 3 available as
> > the 'cmake3' package.
> >
> > On Thu, Feb 14, 2019 at 11:10 PM Hal Murray <hmurray at megapathdsl.net> wrote:
> > >
> > >
> > > dfoxfranke at gmail.com said:
> > > > I think what you did will probably work if you delete your CMakeCache and try
> > > > again
> > >
> > > Thanks.  That is the hint I needed.  I was scp-ing stuff from my main system
> > > to others giving them a bogus cache.
> > >
> > > ---------
> > >
> > > It doesn't build on NetBSD.  Do you recognize the error:
> > >
> > >  [ 11%] Building C object CMakeFiles/runtests.dir/aes_siv_test.c.o
> > > In file included from /usr/include/stddef.h:37:0,
> > >                  from /home/murray/ntpsec/libaes_siv/aes_siv.h:8,
> > >                  from /home/murray/ntpsec/libaes_siv/aes_siv.c:5,
> > >                  from /home/murray/ntpsec/libaes_siv/aes_siv_test.c:3:
> > > /home/murray/ntpsec/libaes_siv/aes_siv.c:114:24: error: expected declaration
> > > specifiers or '...' before '__builtin_constant_p'
> > >  static inline uint64_t bswap64(uint64_t x) { return __builtin_bswap64(x); }
> > >
> > > ---------
> > >
> > > Any chance of building it with an old cmake?
> > >
> > > CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
> > >   CMake 3.0 or higher is required.  You are running version 2.8.12.2
> > >
> > > That's from CentOS.
> > >
> > >
> > >
> > >
> > > --
> > > These are my opinions.  I hate spam.
> > >
> > >
> > >


More information about the devel mailing list