e: Problem to use VFS modules

[Andrew Tridgell]

> I agree it's generally not easy to track problems down when they show
> up, and that they do show up every now and then.  But it works fine
> far more often than it breaks and, when it does, you always have the
> option to --disable-shared.

We don't have that option. The only reason we want shared libraries is
to enable loadable modules via the Samba VFS layer. If the system
can't produce shared libs that we can dynamically load then we want to
disable that feature in Samba. It's a nice feature, but its not
important enough to change everything for.

We definately do not want to build all of Samba as lots of shared
libraries, we *only* want it for VFS modules.

> Everybody that suggests this has no idea of how awkward it is to build
> shared libraries on certain ``non-open source UNIX's and non-UNIX's.''
> GNU/Linux with `gcc -fPIC; gcc -shared' is heaven, and people who are
> limited to this experience often fail to see the point of using
> libtool for these ``simple'' tasks.

true, but if the price we have to pay for that generality is total
conversion to libtool then we'll just support some specific OSes that
we have access to and can test.

I suspect that for the functionality we need in loadable VFS modules
there are actually quite a lot of systems (perhaps the majority?) that
just won't be able to do what we need, but that's OK.

So do you think we can use libtool in such a restrained way? We'd need
it to:

- tell us if the system has the capabilities we need
- compile a .c file with necssary flags so that it can be later put
  into a shared lib
- combine several object files into a shared lib

Cheers, Tridge