----- Original Message -----
> From: "Dennis Clarke" <dclarke_at_blastwave.org>
> To: curl-library_at_cool.haxx.se
> Sent: Tuesday, June 19, 2018 2:53:36 PM
> Subject: Re: Build issues for curl/libcurl > 7.53.1 on OpenServer 5.0.7
>
> On 06/19/2018 08:11 PM, Kevin R. Bulgrien wrote:
> > Having found oneself in a situation where TLS 1.2 is about to
> > become a hard requirement, an opportunity to upgrade a very old
> > (7.15.1) curl/libcurl has arisen.
>
> TLS 1.3 is upon us real soon now and I should think TLS 1.2 has been
> a hard "requirement" for a long long time now.

Perhaps in concept, but in practicality, a rather large provider has
not required TLS 1.2 and is enforcing use of TLS 1.2 as of June 30,
2018. Most of the time we are able to use Linux systems or
third-party resources for secure processing.

> > The environment that needs upgrade is an OpenServer 5.0.7 system.
> > GNU tools are available, and it has been possible to build a
> > number of newer tools in this environment. In fact, it was
> > possible to build up to curl 7.53.1 with only a modicum of
> > fuss needed to adapt to the present state of the build
> > environment; the openssl-1.0.2o.tar.gz LTS release built fine
> > with no issue.
>
> I suggest OpenSSL 1.1.0h and curl 7.60.0 as the place to start.
> Works fine on yet another hard core UNIX environment here :

The openssl 1.0.2o LTS version is supported through some time in
2019, so sufficient for the moment. This is not to say that once
current on curl that it would not be reasonable to move beyond
that. I want to address the hard problems first.

> n0$ /usr/local/bin/openssl version
> OpenSSL 1.1.0h 27 Mar 2018
>
> n0$ /usr/local/bin/curl --version
> curl 7.60.0 (sparc64-sun-solaris2.10) libcurl/7.60.0 OpenSSL/1.1.0h
> zlib/1.2.8 libidn2/2.0.4 libssh2/1.8.0
> Release-Date: 2018-05-16
> Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps
> pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
> Features: AsynchDNS IDN IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP
> UnixSockets HTTPS-proxy
>
> n0$ psrinfo -pv
> The physical processor has 6 virtual processors (0-4 6)
> SPARC64-VII+ (portid 1024 impl 0x7 ver 0xa1 clock 2860 MHz)
> n0$

Your OS is already supported in the curl code base with various
defines and what not. I see evidence. I don't happen to be
that lucky. The problem is that OpenServer didn't require
environment specific patches until 7.53.1, but yours did,
so OpenServer 5.0.7 was long out of support by the time
a need to patch came about.

> > As gcc on this system as been more reliable ...
>
> What rev of gcc do you have on hand and did you bootstrap it
> yourself?

The SCO-built gcc 2.95.3 works in more cases than a working gcc
3.4.6 built from source myself (with a lot of trouble taken to
build up dependencies with the SCO-built tool chain).

I don't always have success linking with the gcc 3.4.6 tool
chain without fiddling around, but I believe it is a defect as
much as that I have not set it all up properly due to moving
fast due to time-urgent needs and being new to the OpenServer
environment. (I've never built and deployed a gcc tool chain
myself prior to this.)

It is technically possible to build a very early 4.0.x gcc on
this platform, but beyond that, support for this platform was
dropped long ago.

> I have had plenty of experience dealing with old systems and fully
> understand the struggle. Even worse are the gnuisms and strange gnu
> extensions tossed into nearly everything open source these days.
 
Per my ongoing investigation, I believe the problem is not so
much a need for a "code patch" as it is to find the correct
include. off_t is not defined in /usr/include/sys/types.h as
it "should". OpenServer 5.0.7 (MP5) has various off_t defined
in the likes of:

  /usr/include/sys/dirent.h
  /usr/include/sys/fcntl.h
  /usr/include/sys/ino.h
  /usr/include/sys/inode.h
  /usr/include/sys/stat.h
  /usr/include/sys/uio.h
  /usr/include/sys/user.h

> > Currently, a build of 7.60.0 blows up as shown here:
> >
> > warnless.c:101:4: #error "SIZEOF_CURL_OFF_T not defined"
> > warnless.c: In function `curlx_uztoso':
> > warnless.c:192: error: `CURL_MASK_SCOFFT' undeclared (first use in
> > this function)
> > warnless.c:192: error: (Each undeclared identifier is reported only
> > once
> > warnless.c:192: error: for each function it appears in.)
> > make[2]: *** [libcurl_la-warnless.lo] Error 1
> > make[2]: Leaving directory
> > `/csdi/admin/kevinb/src/curl/curl-7.60.0/lib'
> > make[1]: *** [all] Error 2
> > make[1]: Leaving directory
> > `/csdi/admin/kevinb/src/curl/curl-7.60.0/lib'
> > make: *** [all-recursive] Error 1
> >
>
> Did you try aclocal and then autoconf to rebuild "configure" locally
> ?

I've used autoreconf as opposed to running the likes of aclocal, et. al.
on their own on other projects, but, no, I didn't think to retry this
after making the aforementioned patch.

Apparently that was all I needed to do!

Thanks!

> I'd need to fire up ( yet again ) a SCO OpenServer implementation in
> vmware to even begin. Good to hear that it is still out there
> running.
>
> Makes me ask if you have prodution application code still running
> there and why not port that elsewhere as opposed to dealing with a
> GNU stack on top of ye old SCO which we all know and love but has
> seen its days?

Well, I've certainly almost every time I get on a mailing list to
ask a question I face these queries, so I probably won't bore you
or myself with dealing with it. Yes, its production code and its
dependencies, size of team and expertise to migrate, business must
go on and the like. I certainly am hoping I can be instrumental
in moving to a more sustainable platform.

-- 
Kevin R. Bulgrien, Network/Software Engineer
http://www.systemsdesignusa.com
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html