Hi
Thank you! A lot of really good input here.
I will look into the
libc / POSIX API layer recommendations you make.
In my reply to Paul Eggert, I think you both uncovered a fundamental issue I had.
I think I am pulling the wrong code.
Definitely we want dev systems to be available for people as well. In fact,
The CI/CD system is really just using a dev system under the covers to do
a build.
I will look into the CI/CD recipe – thanks for the link. The intent is definitely
to fit into each community’s development model so that z/OS can be
‘just another OS’ that the package supports.
From:
Bruno Haible <bruno@clisp.org>
Date: Friday, June 3, 2022 at 03:46
To: Mike Fulton <fultonm@ca.ibm.com>
Cc: bug-gnulib@gnu.org <bug-gnulib@gnu.org>
Subject: [EXTERNAL] Re: Failure running gnulib-tool update on z/OS
Hi Mike,
> 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.
That's great to hear! In particular, it means that
- gperf does not need to be extended to handle EBCDIC as execution character
set; Gnulib uses gperf generated files in various places.
- We won't need to go through the trouble that e.g. ICU had to go through,
changing character literals e.g. from 'A' to 0x41.
> 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.
The first step in this chain should IMO be the libc / POSIX API layer.
Gnulib contains a partial test suite for the POSIX API. (There is also
the official test suite from the OpenGroup. Both are complementary,
because they were created independently.) The focus of the Gnulib test
suite is on frequently-used API functions.
To run this test suite, you first create a so-called testdir, that has
the structure of a GNU source package. You do so on a GNU system (because
that is known to have reliable build tools), e.g. Linux/x86_64 or Linux/s390x:
$ cd gnulib
$ rm -rf ../testdir-posix
$ ./gnulib-tool --create-testdir --dir=../testdir-posix --single-configure `./posix-modules`
Then you transport that directory to the target system, z/OS in this case,
and use
$ ./configure
$ make
$ make check
to test it.
The last time a volunteer has done this, there were quite a number of problems
in various areas. [1]
The response to test failures can be
(a) fixes to the libc, to increase POSIX compatibility,
(b) workarounds in Gnulib.
The workarounds in Gnulib will, of course, benefit only packages that use Gnulib,
whereas fixes in the libc will also help in porting Python, Perl, etc.
> 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.
If you start with the libc / POSIX API layer, it will significantly reduce the
size of patches in packages such as coreutils.
> 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.
For m4, please use the 'm4-branch-1.4' branch [2]. The 'master' branch of this
repository is obsolete. Please note that there is a CI/CD recipe for GNU m4 at [3].
> 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.
That's a good move. But for porting and actually fixing issues, it requires
someone who has access to a system, where they can make ad-hoc modifications
to the source code, use a debugger, inspect the object files, and so on.
Without such an access, developers need to make a modification, check it in,
rerun the CI, grovel through the logs, and repeat. This is very time consuming.
Bruno
[1] https://lists.gnu.org/archive/html/bug-gnulib/2019-11/msg00001.html
[2] https://git.savannah.gnu.org/gitweb/?p=m4.git;a=shortlog;h=refs/heads/branch-1.4
[3] https://gitlab.com/gnu-m4/ci-distcheck