Re: Linking coreutils against OpenSSL

["Theodore Ts'o" <tytso@mit.edu>]

On Sat, Nov 11, 2023 at 09:32:46AM +0200, Julian Andres Klode wrote:
> 
> WRT dlopen(), this is never an appealing solution because you do not
> get any type-checking, you have to make sourceful changes for an soname
> bump. It is an interface you can use for loading plugins (that is, you
> should be in control of what the interface is that you are loading from
> the library object), but it's not really usable for stuff that is outside
> of your control.

There are some caveats, yes, but I *have* made it work.  For example,
see [1].  This allows debugfs in e2fsprogs to use GNU readline (or
BSD's libedit), which is *super* convenient, without requiring forcing
GNU readline to be placed in emergency boot floppies or being added to
essential.

[1] https://github.com/tytso/e2fsprogs/blob/master/lib/ss/get_readline.c

For things which are optional, if there is a soname bump, things won't
stop working.  In the case of coreutils and OpenSSL, sha1sum will just
git a bit slower --- in fact, the speeds that it has today, which has
never been a problem for me, FWIW.  And yes, to add accomodate a
soname bump you might need to make some sourceful changes, but it's
often not that hard to do.  At least for the libreadline functionality
used by debugfs, it's mainly doing a bit of testing, concluding "nope,
the ABI didn't change for the functions that libss cares about", and
just adding the additional SONAME to:

#define DEFAULT_LIBPATH "libreadline.so.8:libreadline.so.7:libreadline.so.6:libreadline.so.5:libreadline.so.4:libreadline.so:libedit.so.2:libedit.so:libeditline.so.0:libeditline.so"

:-)

As another example, I have a pending patch to e2fsprogs that I will
shortly integrating which allows mke2fs to optionally use libarchive,
so that mke2fs -d can take a tarball, but again, without expanding the
dependencies for e2fsprogs.  It's not *that* bad.

						- Ted