[Samba] smbclient for SCO OpenServer 5.0.7

[Kevin R. Bulgrien]

Looking back in the samba mailing list archives, I see not soancient requests
for samba on ancient SCO OpenServer systems.

Recently faced with a situation where a Windows Server upgrade to 2012 R2 and
broke an smbclient upload from a SCO OpenServer 5.0.7 system.  Directory
listings and file deletions did not fail, but all upload attempts produced
empty files on the Windows server (this due, undoubtedly to default
disablement of the SMB1 protocol in Windows Server 2012 R2).

The last version of samba issued for that platform by SCO for 5.0.8 was
3.0.20a - far older than samba 3.6.0 where SMB2 was implemented.

In any event, over the past few days, an attempt has been made to tackle
resolution of this problem.  Here is notice that the non-trivial effort
succeeded at building smbclient 3.6.25 for SCO OpenServer 5.0.7.

Though uninterested in discussing the use of SCO or OpenServer 5.0.7 and all
the swirling negativity regarding ancient systems or unfriendly vendors, but
feel it might be of some unfortunate interest to some in the community.  It
seems in the spirit of FOSS to pass the word along to others.

Though the port/patch is likely less than optimal, a test today did result a
statically linked smbclient executable that successfully transfer files and
generally interacts with a Windows Server 2012 R2 from SCO OpenServer 5.0.7
without enable of the SMB1 protocol.  It was not necessary to uninstall the
native Samba package.

$ uname -srvm
SCO_SV 3.2 5.0.7 i386
$ ./samba-3.6.25/source3/bin/smbclient --version
Version 3.6.25
$ gcc --version
2.95.3

The port largely involved resolving type mismatches related to inconsistent
use of uint32 and uint32_t in different parts of the source tree.  In some
cases, the problem was as simple as prototypes not matching the actual
type declarations.

An edit one line of the configure script to disable a fatal error relating to
a "required" syslog function dependency (as no way to disable the dependency
was found to worked on this platform - though there may be some question as
to whether the correct way to do so was found).

It also seemed necessary to supply various gcc -D arguments as ./configure did
not appropriately detect some capabilities of the platform and resulted in
various `make` fatal errors.  My autotool knowledge is very sparse and it is
openly acknowledged that there is a much better way to have resolved these
issues.

Resolving link failures was a bit more involved.  An S_ISSOCK() macro was not
supplied by system /usr/include files, but this was able to be worked around
with a minor edit.

There was also an issue that /usr/include files did not document provided
strtoll or strtoull functions though it both showed up in a strings search of
libc and libstdc++ shared objects in /usr/lib.  For purposes of compiling
only smbclient, though, it appeared that maybe only strtoull was required.
lib/replace/replace.c did not suffice with respect to providing workarounds.
I resorted to importing strtoull from gnulib to resolve the issue.

12345678901234567890123456789012345678901234567890123456789012345678901234567890
It should be noted, that I made no attempt to resolve build issues not related
to those encountered when running `make bin/smbclient` in the source3 tree.

I am certainly willing to attempt to share patches and the procedure followed
if there are suggestions on a reasonable venue-maybe a VCS branch somewhere.
I know that the official stance toward this platform is one of non-support,
and, this is an incomplete port, but, in the interest of helping people
that find themselves in a pinch, it doesn't seem worth letting salty
attitudes dissuade sharing.  Thoughts?

-- 
Kevin R. Bulgrien