Relocation errors in cdebconf plugins

[Max Vozeler <max@nusquama.org>]

Hi all,

I'm seeing a problem trying to use the cdebconf-entropy plugin
after loading it in a daily build [0] (it does not happen when it
is included in the initrd [1]). In short: cdebconf dlopen()s the
plugin without problem (RTLD_LAZY), but dies with a relocation
error as soon as the plugin uses mlock():

 writev(2, [{"debconf", 7}, {": ", 2}, {"relocation error", 16}, {": ", 2}, {"/usr/lib/cdebconf/frontend/newt/plugin-entropy-text.so", 54}, {": ", 2}, {"symbol mlock, version GLIBC_2.0 not defined in file libc.so.6 with link time reference", 86}, {"", 0}, {"", 0}, {"\n", 1}], 10) = 170

The problem is apparently that mlock() gets stripped from the
early version of libc.so.6 included in the initrd because nothing
in the initrd references the symbol. The libc later installed
from libc6-udeb does include mlock(), but cdebconf gets started
before it is available and so still has the reduced libc loaded.
It seems that the linker continues to try resolve new symbols in
dlopen()ed plugins using the early reduced libc.

  $ nm -B working/libc.so.6 | grep mlock
  0006db40 T mlock
  0006dbc0 T mlockall
  
  $ nm -B non-working/libc.so.6 | grep mlock
  $

If this is indeed the case, I think it means that cdebconf
plugins must either a) use only symbols that are also referenced
in cdebconf itself or something else included in the initrd or b)
be included in the initrd during library reduction. If somebody
can confirm this conclusion, I'll try to add some mention of
this proble to the cdebconf plugin documentation.

I'm a bit at loss how to solve this for cdebconf-entropy. It
would either need to included in the initrd of all builds that
one may want to use partman-crypto in (udeb: 5148 bytes,
installed: 40k), or there would need to be some kind of mechanism
to tell mklibs (it does the reduction, correct?) that certain
symbols should be retained even if they are not used by anything
in the initrd tree.  Any suggestions what I should do?

Regardless of the above case, I think it's quite bad 
if a plugin can take down cdebconf by having unresolved symbols.
The problem is, I think, that when using RTLD_LAZY, there is no 
way to gracefully signal that a problem resolving symbols has
occured after dlopen() has returned. I have tried this yet, but
in theory using RTLD_NOW should prevent this exact problem. It
should make dlopen() return NULL if any unresoved ymbols exist.
I will try to do a build of cdebconf with RTLD_NOW to verify that
it indeed prevents the problem and doesn't break anything and
let you guys know how it worked out.

cheers,
Max

-- 
[0] http://people.debian.org/~joeyh/d-i/images/2006-05-14/netboot/mini.iso
[1] http://nusquama.org/~max/d-i/crypto/2006-05-14/netboot/mini.iso