Re: roland_libstore_modules_branch

[Roland McGrath]

> Indeed!  module.c isn't even part of the compiled source in your branch.

D'oh!  That stuff got shuffled around when I was separating my changes to
make the branch.  I've checked in fixes for those build things now.

> #define STORE_SONAME_SUFFIX ".so.1"
> 
> to
> 
> #define STORE_SONAME_SUFFIX ".so.0.2"

Hmm, I had meant to change that and forgotten about it.  I put in a
makefile hack so it's pegged to $(hurd-version).  But actually the struct
store_class layout might change more frequently than that, and if that
happens and we really have separate packages providing store modules, we
might want to make this soname version number independent and change it as
needed for incompatible interface changes.

> because otherwise it would look for the wrong file.  From the command
> line, it seems to recognize the gunzip store now, both with -T module
> gunzip:file.gz and with -T gunzip file.gz.

What program from the command line?  Do you mean storeinfo/storeread, or
storeio when not run as a translator?

> As a storeio translator, it starts up and dies:

Please step into the dynamic linker here and see what is going wrong.  It
just might be a bug, or it might be that it's not really kosher top call
dlsym on a handle gotten that way.  The particular crash seems to be in
calling dlsym on the map for the executable (l_name is "").  That one we
can always skip anyway, since it's never useful--the dlsym will either
return zero or the &__start_store_std_classes address that is skipped by
the check immediately after the dlsym call.  It might be most kosher to
skip l_name[0]==0 and for the others to do dlopen(l_name),dlsym,dlclose
so as not to be using dlsym a map not returned by dlopen, and keep the open
counts right.

> Note that -T gunzip file:r.gz works fine!

That is pretty odd.  I would expect the store_find_class("gunzip",...) call
to hit the same problems in the dynamic linker before it tries opening the
module file.  But I suppose there might be some dynamic linker bug wherein
the state is changed by the successful dlopen so that the later loop barfs.