build: Add support to build against LibreSSL

[igaw]

LibreSSL ships with the same API but has a different version number
scheme. That is LibreSSL 3.x is not providing the OpenSSL 3.x
APIs. Hence we need to test if the OpenSSL 3 APIs are available if
LibreSSL is present.

Reported-by: Ismael Luceno ismael@linux.com
Signed-off-by: Daniel Wagner dwagner@suse.de

Fixes: #434

[codecov-commenter]

Codecov Report

Merging #439 (8a7cf44) into master (920c3fc) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #439   +/-   ##
=======================================
  Coverage   18.19%   18.19%           
=======================================
  Files          31       31           
  Lines        5206     5206           
  Branches      997      997           
=======================================
  Hits          947      947           
  Misses       3988     3988           
  Partials      271      271           

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 920c3fc...8a7cf44. Read the comment docs.

[ismaell]

-nostdinc makes the build fail for a system with native libressl.

[igaw]

And how so? The pkg-config step should add the right path, no? Without -nostdinc it breaks on my build system where I also have OpenSSL in the standard paths.

[eli-schwartz]

pkg-config will by default filter out system include/library directories, but can be told not to.

However it seems weird that having the standard includes would break anything, because that would also mean that programs which compile with the libressl dependency and also with a dependency that is installed to /usr/include would have compilation errors. Libressl's -I directory should be overriding that, though.

What's the actual error?

[igaw]

Right, I forgot that pkg-config is not adding the default paths. So on my system I installed libressl under /tmp/libressl:

$ export PKG_CONFIG_PATH=/tmp/libressl/lib64/pkgconfig 
$ pkg-config --cflags openssl
-I/tmp/libressl/include 

without -nostdinc

Header <openssl/opensslv.h> has symbol "LIBRESSL_VERSION_NUMBER" with dependency openssl: YES 
Has header "openssl/core_names.h" with dependency openssl: YES 

So the first test finds LibreSSL openssl/opensslv.h but has_header is finding the OpenSSL header file.

Header <openssl/opensslv.h> has symbol "LIBRESSL_VERSION_NUMBER" with dependency openssl: YES 
Running compile:
Working directory:  /home/wagi/work/libnvme/.build/meson-private/tmp9t2xnyda
Command line:  cc -I/tmp/libressl/include /home/wagi/work/libnvme/.build/meson-private/tmp9t2xnyda/testfile.c -E -P -D_FILE_OFFSET_BITS=64 -P -O0 -std=gnu99 

Code:
 
        #ifdef __has_include
         #if !__has_include("openssl/core_names.h")
          #error "Header 'openssl/core_names.h' could not be found"
         #endif
        #else
         #include <openssl/core_names.h>
        #endif
Compiler stdout:
 
Compiler stderr:
 
Has header "openssl/core_names.h" with dependency openssl: YES 

FAILED: src/libnvme.so.1.1.0.p/nvme_linux.c.o 
cc -Isrc/libnvme.so.1.1.0.p -Isrc -I../src -I. -I.. -Iccan -I../ccan -Iinternal -I../internal -I/usr/include/uuid -I/usr/include/json-c -I/tmp/libressl/include -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=gnu99 -O3 -fomit-frame-pointer -D_GNU_SOURCE -include internal/config.h -fPIC -MD -MQ src/libnvme.so.1.1.0.p/nvme_linux.c.o -MF src/libnvme.so.1.1.0.p/nvme_linux.c.o.d -o src/libnvme.so.1.1.0.p/nvme_linux.c.o -c ../src/nvme/linux.c
In file included from /usr/include/openssl/e_os2.h:14,
                 from /usr/include/openssl/types.h:20,
                 from /usr/include/openssl/core.h:15,
                 from /usr/include/openssl/params.h:15,
                 from ../src/nvme/linux.c:27:
/usr/include/openssl/macros.h:155:4: error: #error "OPENSSL_API_COMPAT expresses an impossible API compatibili

[igaw]

I suppose we can drop the -nostdinc as it shouldn't break any OpenSSL systems.

[eli-schwartz]

Ah yeah, because header includes are the union of all include paths. The header does exist in at least one place, and just because its parent directory is shadowed by another include path, doesn't mean that individual header is.

Maybe that test could be gated on the openssl API version as well as whether the header exists?

[igaw]

Usually only one library is present and only if you have both libraries in the include path things will break. So my test is a bit artificial. Let's just drop the -nostdinc and if someone really wants to get this setup working, I am happy to review patches.

[ismaell]

The problem with using -nostdinc is that pkg-config drops system directories unless the PKG_CONFIG_ALLOW_SYSTEM_CFLAGS environment variable is defined. So any headers installed to /usr/include will not be found.