Re: Moving libcrypto.so.* back to /lib

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Once upon a time, Richard W.M. Jones <rjones@xxxxxxxxxx> said:
> On Fri, Apr 09, 2010 at 10:26:01AM -0500, Chris Adams wrote:
> > Once upon a time, Richard W.M. Jones <rjones@xxxxxxxxxx> 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@xxxxxxxxxx>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux