[Samba] smbclient for SCO OpenServer 5.0.7

[Jeremy Allison]

On Wed, Sep 12, 2018 at 03:27:37PM -0500, Kevin R. Bulgrien via samba wrote:
> 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?

I'm always interested in seeing Samba get built for old/exotic
architechures and platforms - however 3.6.x is *way* out of
support, so there's no chance this patch could get merged.

If you want to make it useful for others, you could always log
a bug (which you or we will mark as WONTFIX due to the age of
the code) and then upload your patch file as an attachment.

At lease then we have a record of your achievement that you
can point people having similar issues at !

Cheers,

	Jeremy.