e: Problem to use VFS modules

[Alexandre Oliva]

On May 14, 2001, root <root at samba.org> wrote:

> This debate certainly is interesting!
>> > - tell us if the system has the capabilities we need
>> 
>> libtool --features | grep "enable shared"

> I probably should have been more explicit. We need the following
> features from the OS:

> 1) shared libraries

> 2) the ability to dlopen() the libraries at runtime with a given (not
>    OS mandated) path

> 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.

Then, you can test with libtool --config | grep '^dlopen_support=yes'

> 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'

> 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?  If the latter, the test would be

libtool --config | grep '^allow_undefined=' |
grep -v '^allow_undefined=unsupported$'

It verifies whether a shared library can refer to symbols not defined
in any of its dependencies.

>> libtool --mode=compile $(CC) $(CPPFLAGS) $(CFLAGS) -c foo.c
>> 
>> this creates foo.lo

> I assume we can use -o to say where to put the object file?

Yep.  Libtool will take care of moving it if the compiler doesn't
support it directly.

>> > - combine several object files into a shared lib
>> 
>> libtool --mode=link $(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) \
>> foo.lo bar.lo ... -o libbaz.la -rpath $(libdir)
>> 
>> Then, at install time:
>> 
>> libtool --mode=install install -c libbaz.la $(libdir)/libbaz.la

> The separation of build and install would be a pain for Samba.

Why?  Don't we install the library at `make install' time?  All you
have to do is use this command instead of the one that copies the
shared library to libdir.

Add $(DESTDIR) before $(libdir) and you should be all set for
packaging.

> 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.

You may also want to use -version-info when creating the library, so
as to be able to maintain binary compatibility, but this is probably
not useful for this particular library.  In fact, you may want to
create this library as a -module (something that can be dlopened and
won't be compile-time -linked with), or at least to link it with
-export-dynamic (so that it can still be -linked with).

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me