e: Problem to use VFS modules

[root]

> > 3) the ability to find functions in the shared libraries with dlsym()
> 
> Is using libltdl an option?  It's a portable dlopening interface that
> supports a number of dlopening mechanisms.

Possibly, I haven't looked into it.

> > 4) functions in the shared libraries need to be able to access global
> >    symbols in the main executable
> 
> As in dlopen(NULL)?  This can be tested with libtool --config | grep
> '^dlopen_self=yes'

no, just by referencing them. That allows modules to (for example)
call DEBUG() and all the lp_*() loadparm functions.

> > 5) functions in shared libraries need to be able to access functions
> >    from other shared libraries that have been previously loaded (so we
> >    can chain loadable modules)
> 
> Libtool doesn't have any built-in tests for that.  In fact, I'm not
> sure I understand how you'd do that: using dlopen(NULL) then dlsym(),
> or by simply referring to the symbols in the shared library, expecting
> the dynamic linker will resolve them into symbols offered by other
> shared library, even though you don't explicitly link your shared
> library with it?

Using function pointers. The parent smbd will pass a structure
containing a bunch of function pointers to the loaded library, and
some of those function pointers may have come from other loaded
libraries (ie. they will have come from a dlsym() on a different
library).

> > is there any need for this separation given the restricted use we
> > are making of shared libs in Samba?
> 
> Well, there's the issue of adjusting the permission of the installed
> shared library (because cp isn't guarantee to preserve permissions),
> and creating the soft-links so that the SONAME and the .so point to
> the actual shared library.

The soft-links won't matter. These are not shared libs that will ever
be linked against, so the name will be chosen by smbd constructing a
string and passing it to dlopen(). 

For permissions we can just use install like we do now. I don't think
the weird AIX permission bits are a great worry (I have a couple of
AIX boxes, so I can play with that and see what it does).

btw, after the great debate about libtool, my inclination is that we
create the two shell scripts I mentioned earlier (a script that
compiles to PIC and one that creates the lib) then have using libtool
as one option within that script, and leave it as the trivial CFLAGS
and LDFLAGS switch for the major OSes that we know about. Once I
become more familiar with libtool maybe I'll be confident enough in it
to use it on all OSes. By doing this we can be sure that libtool usage
is isolated to within those two scripts. We won't use a .libs/
directory, and won't use libtool for install.

Cheers, Tridge