Moving libcrypto.so.* back to /lib

[Chris Adams]

Once upon a time, Richard W.M. Jones <rjones at redhat.com> said:
> On Fri, Apr 09, 2010 at 10:26:01AM -0500, Chris Adams wrote:
> > Once upon a time, Richard W.M. Jones <rjones at redhat.com> said:
> > > libguestfs builds its appliance on the fly by concatenating together
> > > files [library files, binaries and data files] from the host.  We
> > > express this requirement by mapping the location of those files into
> > > dependencies.
> > 
> > Why can't it just depend on libcrypto.so.<vesion>, and then use the
> > linker to find the libraries at run-time?
> 
> Because it's not linking with the library, it's copying it (along with
> many other non-library-like files) into an appliance.

So?

$ ldconfig -p | grep "libcrypto\.so\." | sed 's/.* => //'
/lib/libcrypto.so.8

Granted, it would take another line or two to handle multilib, but
that's it.

If you wanted to get fancy, you could use the C compiler (avoids having
to directly deal with multilib), but that requires -devel packages
installed.  Even better would be to do this at RPM build time; link an
empty program against all of the libraries you need and just install the
resulting no-op binary somewhere.  Then use "ldd" to find all the
dependencies (like the old mkinitrd script did).

$ echo 'main(){}' | cc -lcrypto -o findlib -x c -
$ ldd findlib
	linux-vdso.so.1 =>  (0x00007fffdab7c000)
	libcrypto.so.8 => /usr/lib64/libcrypto.so.8 (0x000000354ae00000)
	libc.so.6 => /lib64/libc.so.6 (0x00000038f2200000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00000038f2a00000)
	libz.so.1 => /lib64/libz.so.1 (0x00000038f3200000)
	/lib64/ld-linux-x86-64.so.2 (0x00000038f1e00000)

You copy everything from the ldd output (except for the VDSO bit
obviously), which should make sure you get any dependencies (except for
dlopen() libraries, but that is actually hard to handle in an automated
way).

> Now you may think that this is a bad way to build an appliance, but no
> one has come up with any better ideas for that so far.

It isn't hard to find a shared library without hard-coding static paths.
-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.