On Wed, Oct 22, 2025 at 10:06 PM James K. Lowden <[email protected]> wrote:
>
> On Wed, 22 Oct 2025 10:20:48 +0200
> Richard Biener <[email protected]> wrote:
>
> > >         * posix/.gitignore: New file.
> > >         * posix/README.md: New file.
> > >         * posix/cpy/posix-errno.cbl: New file.
> > >         * posix/cpy/statbuf.cpy: New file.
> > >         * posix/cpy/tm.cpy: New file.
> > >         * posix/headers: New file.
> > >         * posix/scrape.awk: New file.
> > >         * posix/sizeofs.c: New file.
> > >         * posix/udf-gen: New file.
> > >         * posix/udf/Makefile: New file.
> > >         * posix/udf/posix-exit.cbl: New file.
> > >         * posix/udf/posix-localtime.cbl: New file.
> > >         * posix/udf/posix-mkdir.cbl: New file.
> > >         * posix/udf/posix-stat.cbl: New file.
> > >         * posix/udf/posix-unlink.cbl: New file.
> > >         * posix/udf/t/errno.cbl: New file.
> > >         * posix/udf/t/exit.cbl: New file.
> > >         * posix/udf/t/localtime.cbl: New file.
> > >         * posix/udf/t/stat.cbl: New file.
> >
> > These new directories/files caught my eye and I don't see them
> > mentioned in any of the Makefile changes (but maybe I missed this).
> > Are those files to be installed and used by gcobol upon compile
> > time?  The main question is whether those should be part of libgcobol
> > instead if they are some sort of "system headers" for the target?
>
> 'some sort of "system headers"' is about right.  :-)
>
> Some of the files mentioned above weren't intended for GCC.  That's my
> mistake; let me clarify below.  Others want to be installed for the
> user's benefit.
>
> 1.  The files in gcc/cobol/posix/udf provide COBOL bindings to POSIX
> functions. In some cases they call e.g. unlink(3) directly.  Others
> require C support provided by libgcobol.so, by files in
> libgcobol/posix/.
>
> 2.  The files in gcc/cobol/compat/lib/gnu emulate a utility library
> originally defined by MicroFocus.  It's under "gnu" instead of, say,
> "mf" because some of them have been re-implemented by GnuCOBOL,
> and our implementation follows those insofar as our tests are correct.
> It's not directly under "lib" because we anticipate other emulation
> libraries.
>
> Both #1 and #2 are to be installed because they're to be used by the
> person using gcobol.  i have not yet added them to the install target.
>
> The following 5 files sneaked in and aren't intended for GCC.  They're
> local development files that we keep in our repository as a
> convenience.  We will remove them from the proposed patch:
>
> > >         * posix/headers: New file.
> > >         * posix/scrape.awk: New file.
> > >         * posix/sizeofs.c: New file.
> > >         * posix/udf-gen: New file.
> > >         * posix/udf/Makefile: New file.
>
> Files in gcc/cobol/posix/udf/t should IMO be part of the GCC
> repository, but are not installed.  They are local tests meant to make
> sure the .cbl files compile and return reasonable results.
>
> If the Makefile is controversial I will remove it.  It's convenient if
> the user has GNU Make installed and is developing new UDFs.  I don't
> think it's worthwhile to convert to Makefile.am.
>
> > >         * posix/udf/Makefile: New file.
> > >         * posix/udf/t/errno.cbl: New file.
> > >         * posix/udf/t/exit.cbl: New file.
> > >         * posix/udf/t/localtime.cbl: New file.
> > >         * posix/udf/t/stat.cbl: New file.
>
> The rest -- files ending in .cpy and .cbl -- are to be used as
> "header libraries" in the STL sense.  The COBOL program may use the COPY
> statement to incorporate them in the translation unit being compiled.
> So, yes, they should be installed in something
> like /usr/include/gcc/cobol/posix/udf.
>
> Please tell me if that name is acceptable.  When we create new
> directories, do they all need an explicit "make new directory" patch?
> Or just those that affect the gcc directory and/or install target?

To allow easy parallel install of gcobol-16 and later it might be better to
follow how 'finclude' system headers are handled which are put into
for example

> ls /usr/lib64/gcc/x86_64-suse-linux/13/finclude/
ieee_arithmetic.mod  omp_lib.h            openacc.mod
ieee_exceptions.mod  omp_lib.mod          openacc_kinds.mod
ieee_features.mod    omp_lib_kinds.mod    openacc_lib.h
omp_lib.f90          openacc.f90

the alternative is to use a location similar to the C++ standard
library includes
which is

/usr/include/c++/13/

for example.

> The user could, at his discretion, choose to compile any part
> of gcc/cobol/posix/udf/*.cbl to a shared object or static library.  We
> are supplying them as COBOL source only.

OK.  I'm still wondering whether the files should reside in
libgcobol/.. instead given they are "for the target" (even if just as
source).  I'm thinking of a possible future need to "preprocess" them
for example to cater for AIX/BSD/Linux differences in POSIX API uses.

It might also ease to eventually build those into (static) libraries to
avoid the need to somehow build them on the users side.

> As it stands, the work is incomplete.  There are more POSIX bindings to
> write.  Those bindings are used by the compat library, which is barely
> begun but should have 10 functions in time for GCC 16.  We don't have
> tests for the compat functions, which are really the end-to-end test
> for the whole stack.  (libc -> [C shim] -> posix/udf -> compat).
>
> To recap:
>
> 0.  Still not sure what to do about new directories.
> 1.  We we remove files included by mistake.
> 2.  The Makefile can stay or go, as you prefer.
> 3.  The test files belong in the repository, but are not installed.
> 4.  The COBOL source files are to be installed and compiled by the
> user.

I'd say as long as the files are not installed we don't have to put them
into the repository at this point and can defer this to a future change?

> TODO:
>
> 5.  Add #4 to the install target.
> 6.  compat functions, tests, and documentation are TODO for GCC 16.

Indeed, a libgcobol testsuite that does this 'COPY' of one of the system
headers and tests the workings would be nice to have.

Richard.

>
> --jkl

Reply via email to