[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 0/4] Use AF_ALG in checksum utilities
From: |
Bruno Haible |
Subject: |
Re: [PATCH 0/4] Use AF_ALG in checksum utilities |
Date: |
Tue, 24 Apr 2018 15:28:51 +0200 |
User-agent: |
KMail/5.1.3 (Linux/4.4.0-119-generic; KDE/5.18.0; x86_64; ; ) |
Hi Matteo,
> > * As you already noticed, we need to avoid build failures and runtime
> > failures
> > on platforms where this is not supported.
> >
>
> I see "#ifdef __linux__" already in use in gnulibs, I assume this is
> the preferred way.
Not really. When being compiled on an older Linux machine, that does not have
the
necessary include files, this "#ifdef __linux__" would lead to a compilation
error.
Therefore the preferred way is to test for the essential header files. For
example,
suppose AF_ALG gets defined by <linux/foobar.h> and is present in every version
of
<linux/foobar.h> (even the oldest ones). Then in the Autoconf macro we would
need
AC_CHECK_HEADERS([linux/foobar.h])
and in the code we would have
#if HAVE_LINUX_FOOBAR_H
> > * In the module description, section 'Include', you should not list all
> > include
> > files but only those that the user is supposed to include. In this case,
> > I think, the af_alg business is invisible to the caller of the 4
> > modules.
> >
>
> How to conditionally add files to lib_SOURCES depending on the system?
> I guess that such code snippet is pasted somewhere in the Makefile, so
> something like should work:
>
> lib_SOURCES += sha1.c
> UNAME_S := $(shell uname -s)
> ifeq ($(UNAME_S),Linux)
> lib_SOURCES += af_alg.c
> endif
>
> or do you have a better solution?
This "solution" would not work when cross-compiling from Linux to non-Linux
platforms or vice versa.
It is better to rely only on the preprocessor defines, such as
HAVE_LINUX_FOOBAR_H.
It is perfectly OK to have a compilation unit that looks like this:
#include <config.h>
#include <unistd.h> /* or other general include files */
#if HAVE_LINUX_FOOBAR_H
# include <linux/foobar.h>
... Here comes the actual code ...
#endif
In the worst case, this generates a .o file without any function definition.
This is OK. (It generates a warning on AIX, IIRC, but that warning can be
ignored.)
Bruno