apisupport.sh: pass ${LDFLAGS} when testing for api features

[Villemoes]

I'm trying to create a recipe for building the tarsnap client with Yocto, in both native and target variants.

One problem I've hit for the native variant is that Yocto tries very hard to rely on host tools as little as possible, and builds as many native tools and libraries as possible, in order to have a reproducible build environment.

So Yocto does rely on the build host providing a working C compiler, but something like openssl is built using that, and then any other native tools that need openssl will be linked against that specific version. To that end, Yocto ensures that all recipes have a value of LDFLAGS set appropriately, e.g.

export LDFLAGS="-L[...]/x86_64-linux/tarsnap-native/1.0.41/recipe-sysroot-native/usr/lib [...]"

However, this is not taken into account in the api support detection logic. So the first attempt to build
apisupport-LIBCRYPTO-LOW_LEVEL_AES.c fails as expected due to the deprecation

error: ‘AES_set_encrypt_key’ is deprecated: Since OpenSSL 3.0 [-Werror=deprecated-declarations]
11 | AES_set_encrypt_key(key_unexpanded, 128, &kexp_actual);
| ^~~~~~~~~~~~~~~~~~~
In file included from ../sources/tarsnap-autoconf-1.0.41/libcperciva/apisupport/Build/apisupport-LIBCRYPTO-LOW_LEVEL_AES.c:3:
[...]/x86_64-linux/tarsnap-native/1.0.41/recipe-sysroot-native/usr/include/openssl/aes.h:50:5: note: declared here
50 | int AES_set_encrypt_key(const unsigned char *userKey, const int bits,
| ^~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors

But the second attempt including the -Wno... compiler flag also fails:

[...]/hosttools/ld: cannot find -lcrypto: No such file or directory
collect2: error: ld returned 1 exit status

Fix that by taking the user provided LDFLAGS into account.

[gperciva]

Interesting! In libcperciva and kivaloo (which uses pure POSIX Makefiles), our github actions uses LDADD_EXTRA, which is already in apisupport.sh:
https://github.com/Tarsnap/libcperciva/blob/master/.github/workflows/compile.yml#L85

But scrypt and tarsnap (which use autotools) try to set LDFLAGS... but they're setting it with a blank LDFLAGS_OSX, so it doesn't actually matter if it works or not.

I'm trying to work out what's happening. But at first glance I agree that it makes sense to add LDFLAGS to apisupport.sh.

[Villemoes]

Yes, I did notice that LDADD_EXTRA, but I'd prefer to not have to define some non-standard variable if possible. FWIW my current recipe is

### tarsnap_1.0.41.bb
require ${BPN}.inc

SRC_URI = "https://www.tarsnap.com/download/tarsnap-autoconf-${PV}.tgz"
SRC_URI[sha256sum] = "bebdbe1e6e91233755beb42ef0b4adbefd9573455258f009fb331556c799b3d0"

S = "${UNPACKDIR}/${BPN}-autoconf-${PV}"

SRC_URI += "file://0001-apisupport.sh-pass-LDFLAGS-when-testing-for-api-feat.patch"

### tarsnap.inc
SUMMARY = "Online backups for the truly paranoid"
DESCRIPTION = "Tarsnap is a secure, efficient online backup service."
HOMEPAGE = "https://www.tarsnap.com"

LICENSE = "Tarsnap"
LIC_FILES_CHKSUM = "file://COPYING;md5=75a55ddd4797983160bcc38ac0fd638a"

inherit autotools pkgconfig

DEPENDS += "e2fsprogs"
DEPENDS += "openssl"
DEPENDS += "zlib"

BBCLASSEXTEND = "native nativesdk"

EXTRA_OECONF += "--program-prefix=''"

CFLAGS:append = " -Wall -Wextra -Werror -Wno-error=implicit-fallthrough -Wno-error=clobbered -D_FORTIFY_SOURCE=2"

do_compile:prepend() {
    # Generate these two files serially to avoid the "checking if ... [yes/no/...]" lines getting intermingled in the output.
    oe_runmake -j1 apisupport-config.h cpusupport-config.h
}

PACKAGES =+ "${PN}-keygen  ${PN}-keymgmt  ${PN}-keyregen  ${PN}-recrypt"
FILES:${PN}-keygen = "${bindir}/tarsnap-keygen"
FILES:${PN}-keymgmt = "${bindir}/tarsnap-keymgmt"
FILES:${PN}-keyregen = "${bindir}/tarsnap-keyregen"
FILES:${PN}-recrypt = "${bindir}/tarsnap-recrypt"

The extra SRC_URI .patch is this PR, and the extra line in do_compile is explained by the comment and was mostly because I had occasion to even look at the do_compile log file. Other than that it should be fairly standard and minimal.