SMB Client with Perl module

[John E. Malmberg]

"Alain" <alian at alianwebserver.company> wrote

> John Malmberg wrote:
> > The OpenVMS port of SAMBA 2.0.6 has the following
> > libraries built as shared libraries.
> > ...
> > These libraries are statically linked as shared, but there is no
> > restriction on loading them dynamically if a program chose to
> > do so.
>
> I don't know difference between OpenVMS port and other. Can this
> feature be ported to other plat-form ?

Probably.  The link commands for VMS are quite different from other
operating systems, and I am not familiar enough with UNIX syntax to
translate.

On OpenVMS shared libraries are called shared images.

With VMS, it is just a matter of providing a text input file to the linker
that contains a list of the global symbols that are to be made visible
outside of the image, and telling the LINKER to produce a shared image.

On the VAX architecture, OpenVMS can use an additional file containing
transfer vectors.  Transfer vectors are basically a jump table that is
placed by the linker at a specific place in the shared image so that
programs that are statically linked against the shared image do not need to
be relinked should the location that the actual routine resides at changes.
For the ALPHA archecture, this is handled automatically by the linker in
most cases.

So creating a shared image out of a library is simple thing to do by just
changing the link commands.

OpenVMS does have a restriction that all symbols used by a shared image must
be resolved internal to the shared image, or by another shared image that it
is statically linked against.

Therefore for SAMBA 2.0.6:

The LIB and PARAM libraries had too many interdependancies to be built
separately as shared images.  By combining them together, all of their
symbols were resolved.

The LIBSMB library relies on symbols from the shared image built above.

So for 2.0.6. it works out well.  What I do not have is separate
documentation of how to use those routines outside of SAMBA.

How did I find what global variables were used?  Brute force.  I did not
declare any, and let the linker complain what symbols it could not resolve,
and then declared them in the shared images where they were needed.

This basically is reverse engineering as the libraries were probably not
designed to be shared images.

If you are interested in looking at the code, please see:

http://eisner.decus.org/~malmberg/samba/

> > > btw...I think this is a good idea :-)  Ever better is to wrap
> > > the client side RPC calls into an administrative module
> > > for handlind remote NT clients from your UNIX host.
>
> So I first take a look at smbwrapper code, but I can't build them on my
> Linux box (new glibc problem, I see it on deja)
> When build smbw.c, I've error like "dereferencing pointer to incomplete
> type", so .....

SMBSH compiled and linked on OpenVMS.  I have not tested it, nor have I
looked into what it can do.  SMBFILTER and SMBSPOOL are also in the same
state.

> > I am not aware of any document that explains how to use any of these
> > shared libraries by other than the SAMBA program.  Such would be nice to
> > have.
>
> If I've the .h et .so, no problem to build the Perl module (and others
> languages!) . But I haven't this library; So how can I build them (In
> waiting for Samba Core team developpement include them in next release)
> ? Update makefile when build smbclient for have my .so library ? Sorry
> for my so puny english :-(

As I explained above, on OpenVMS converting an object library to a shared
image (.so) is a trivial operation once all the public global symbols are
known.  Converting the link command of a program to use a statically linked
shared image instead of an object library is also trivial.

I do not know the UNIX equivalent syntax, and so I do not know how hard it
would be to do this on UNIX.

And be aware that since the SAMBA team is not currently building these
libraries as shared images with a defined "public" interface, there is no
garantee from them that the entire interface will not change from one
release to another.  This would affect any perl modules or other external
programs greatly.

As SAMBA matures, I would recommend that they start using statically linked
shared images (If I have concept correct for UNIX) instead of object
libraries.

-John
wb8tyw at qsl.network
malmberg at esiner.decus.org