Static linking doesn't work

[randombit]

Description

configure has an --enable-shared=no option, but it doesn't work

Steps to Reproduce

1. ./configure --enable-shared=no
2. make

Expected Behavior

Libraries would be built, and I wouldn't have to fuss with a 10 element long LD_LIBRARY_PATH trying to get rnp_tests to run under gdb.

Actual Behavior

Build failure. The problem is the libraries are mutually dependent, for example librekey depends on bufgap (from librnp), but librnp depends on librekey.

I kind of understand why these libraries are in distinct areas, but not why they are actual independent shared objects, given that they all depend on each other both at build and run time.

[dewyatt]

Related, so going to quote and continue discussion here:

@ni4 said: Looks like I hit #579 within this PR, using the gcc. In some of commits I removed usage of functions from librnp, and now gcc doesn't build (even while command line includes librnp). Actually, we should do something with those mutual dependencies. Right now all top-level functionality is bundled within librepgp and librekey, however both depends on librnp. And librnp also depends on librepgp/librekey. @dewyatt @ronaldtse Any thoughts? Logically, we have 4 entities now: low-level - almost everything in lib folder, used by librepgp/librekey. Now included in librnp. librepgp - all major pgp functionality, i.e. packet parsing, some of cryptography, etc. librekey - key-related functions, depends on librepgp (for packet parsing, signatures, etc). ffi api and old api (rnp.c, used in rnp CLI) - currently it is inside of low-level dir, however, logically, it should be separated. Since it depends on librepgp, librekey. So I see the following ways to resolve this: have 4 libs (librnp, librepgp, librekey, librnpapi), have 3 libs (librnp, librepgp + librekey, librnpapi), have 2 libs (librnp + librekey + librnpapi, librnpapi), and, for sure, single lib. Names could be changed, of course.

@ronaldtse said: @ni4 I prefer the 4 library approach but let's see if @dewyatt thinks otherwise. The reason I prefer separate librepgp and librekey is that not all key stores are supposed to use OpenPGP packets like the keyring.

(I'll reply here when I get a chance to look closer at our options. It's clearly a bit messy right now.)

[ni4]

Recently, during key packet related work, I digged into almost any source file, and I would suggest separation into the following layers:

• librnpcrypt - all cryptography. Symmetric, assymmetric, hash, s2k, key material. Another reason to separate crypto lib is to have theoretical possibility to switch to another crypto lib, once it is needed due to some reasons.
• librnppgp - all OpenPGP-related things, including keys, packets and streams. I don't see a good way to separate between keys and streams, since keys depends on packets parsing and streams, while streams massively depend on keys (encryption-decryption-signing-verification).
• librnpapi - FFI API, and upper level API (part of it is currently in rnp.c).

[dewyatt]

This was fixed during the CMake switchover. The library split discussion has a separate issue somewhere I think (or we can create one).