Always build "internal" library as static

[SWilson4]

Since liboqs-internal (see #1667) is never actually installed on the user's system, it doesn't make sense to build it as a shared library and then link the test programs against it. This PR forces liboqs-internal to be built as a static library regardless of the BUILD_SHARED_LIBS variable.

Fixes #1723.

• Does this PR change the input/output behaviour of a cryptographic algorithm (i.e., does it change known answer test values)? (If so, a version bump will be required from x.y.z to x.(y+1).0.)
• Does this PR change the list of algorithms available -- either adding, removing, or renaming? Does this PR otherwise change an API? (If so, PRs in fully supported downstream projects dependent on these, i.e., oqs-provider will also need to be ready for review and merge by the time this is merged.)

[baentsch]

This PR forces liboqs-internal to be built as a static library regardless of the BUILD_SHARED_LIBS variable.

Hmm -- does this also guarantee that the (test) executables then are statically linked (to the symbols in the internal lib) while they're still dynamically linked to the symbols in the public (shared) lib?

[vt-alt]

I tested the patch and it looked good. Test binaries still linked to liboqs.so.5 (and there is no liboqs-internal.so anymore):

builder@x86_64-p10:~/tmp/liboqs-buildroot$ ldd usr/bin/oqs-test-sha3
        linux-vdso.so.1 (0x00007ffe185ec000)
        liboqs.so.5 => not found
        libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007f0fcdc42000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f0fcdc21000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f0fcda48000)
        libz.so.1 => /lib64/libz.so.1 (0x00007f0fcda2a000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f0fcda24000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f0fcdf5a000)

It says not found because it's inside of buildroot (temporary dir where liboqs is installed).

[SWilson4]

Hmm -- does this also guarantee that the (test) executables then are statically linked (to the symbols in the internal lib) while they're still dynamically linked to the symbols in the public (shared) lib?

Yes, I believe so. (Based on the test executables now running if liboqs-internal.a is removed but not if liboqs.so.5 is removed.)

[jgoertzen-sb]

LGTM! Edit: I always forget to use my personal account... sorry

[Martyrshot]

LGTM (But from this account)

[dstebila]

Thanks @baentsch! The discussion in the OQS status call yesterday was that we would tag an -rc2 after this landed, which I will do tonight unless I hear otherwise.