RE: Failure running gnulib-tool update on z/OS

[Mike Fulton]

Hi,

 

Definitely our goal is to make z/OS a first class development platform, 

and not just a target platform. A few of us in the z/OS community

have started down this path back in December and we are working our

way up the tool chain. 

Our approach is to build these tools as 64-bit ASCII-based (not EBCDIC-based)

now that z/OS has good support for ASCII and UTF8 in the system.

So far, we have been working with the various communities and creating

patches to the supported tarball and/or the git dev line for the different 

tools. The goal is to keep the patches as close to 0 as possible by upstreaming

as we go. 

‘bash’ is higher up the stack (along with zsh). So – they are definitely something

we plan to do – we just haven’t got that far up the stack yet. 

Here is our starter list of ports we are working on: https://github.com/ZOSOpenTools

Some like Perl, m4, make are relatively far along. We have up-streamed many 

Perl patches with the guidance of Karl Williamson for example. m4 has patches

I have developed for the tarball build, but I am now working on getting the git dev

line to build so that I can bring patches forward for upstreaming. 

 

We also have CI/CD public facing systems we use for ensuring we not only get 

The code running, but keep it running. We plan to make these systems available

more broadly very soon and integrate them into continuous build processes for the

open source packages, where the open source communities are willing. 

 

This approach of ASCII-based tools is consistent with what IBM and Rocket have been

doing for awhile now. The big shift is to do this all in the open rather than doing one-off

ports (Node.js, Go, Python, clang, Java are all available for free with optional S&S through
IBM and a variety of tools like git and bash are available from Rocket through their anaconda 
tooling for free with optional S&S). 

The first on the ‘developed completely in the open’ is Perl: 
https://github.com/ZOSOpenTools/perlport where I got it up and running with Karl’s help

then got patches upstreamed and we have the source and binaries and build all available

(the perlport repo is strictly for build scripts and patches and docs – it pulls in the actual
code from the perl ‘blead’ line). The binaries we build through our CI/CD Jenkins server
are at: https://github.com/ZOSOpenTools/perlport/tags

 

Thanks, Mike 

 

 

From: Bruno Haible <bruno@clisp.org>
Date: Tuesday, May 31, 2022 at 05:15
To: bug-gnulib@gnu.org <bug-gnulib@gnu.org>
Cc: Mike Fulton <fultonm@ca.ibm.com>
Subject: [EXTERNAL] Re: Failure running gnulib-tool update on z/OS

Hi,

Mike Fulton wrote:
> I am attempting to bootstrap m4 on z/OS which uses gnulib-tool.

We need to distinguish two concepts: The development platform and the
target platform.

* The target platform is the type of system where the collected C code is
  being run. Gnulib attempts to support a lot of target platforms.
  See [1] for more info about the target platforms.

* The development platform is the type of system where 'git clone',
  'gnulib-tool', 'automake', 'autoconf', 'gperf' etc. are being run.
  Not all target platforms are usable as development platforms:
    - embedded systems, due to lack of memory,
    - native Windows platforms, due to trouble with file names and path names,
    - platforms with an absent or deficient /bin/sh, such as Android and
      Solaris 10.

Note: The C compiler is sometimes used on the target platform, sometimes
on the development platform.

z/OS is not even listed among the supported target platforms [1], because no
one is regularly running the Gnulib test suite on this platform. But with
some effort (especially to resolve the pervasive ASCII vs. EBCDIC problems on
this platform) there is a possibility that it could be got working.

Using z/OS as a development platform, OTOH, requires decent ports of the
development tools. Your mail seems to indicate that /bin/sh is a major stumbling
point. Another one will likely be gperf (which assumes ASCII).

Therefore my recommendation is to use a GNU system as development platform
and z/OS as target platform only. This means, create a tarball of sources
on the GNU system and compile it on the target platform.

Bruno

[1] https://www.gnu.org/software/gnulib/manual/html_node/Target-Platforms.html