[Well, that was interesting. Some combination of fat fingers crashed
my mail client and sent the incomplete message. Continued below]
From: "James K. Lowden" <jklow...@schemamania.org>
To: Matthias Klose <d...@debian.org>
Cc: gcc-patches@gcc.gnu.org
Date: Tue, 4 Feb 2025 04:25:23 -0500
Subject: Re: The COBOL front end, in 8 notes + toplevel patch
On Mon, 16 Dec 2024 10:24:23 +0100
Matthias Klose <d...@debian.org> wrote:
> On 14.12.24 15:38, Matthias Klose wrote:
> > I tried to use the patches to build binary packages for Debian.
> > Found some issues:
>
> tried to build libgcobol on more architectures, please find the
> attached patch to disable building libgcobol on some architectures.
Thanks for the patch, Matthias! For weeks I've been asking myself how
to restrict builds for gcobol to supported architectures, only to
realize the answer was just to apply your patch.
Below is status of each issue you raised.
>
> how should patches and build failures be reported at this point?
As is convenient for you. Here on the list, or in the issues at
https://gitlab.cobolworx.com/COBOLworx/gcc-cobol/-/issues
> I tried to use the patches to build binary packages for Debian. Found
> some issues:
>
> gcc/cobol:
>
> - the config-lang.in is provided in both patch 04 and patch 08.
fixed
> - the installation path for the gcobc script is missing the gcc/
> subdir. Does it make sense to ship the script without the udf
> files?
fixed
> - same for cobol/udf/*, also the udfdir macro is undefined, and
> the files are missing.
fixed
> - the installation of the gcobol.1 man page doesn't honor the
> prefix and the suffix form the configury.
I don't know how to do this. "make -C gcc install" currently
produces:
$ find /tmp/gcc/ | grep cobol
/tmp/gcc/libexec/gcc/x86_64-pc-linux-gnu/15.0.1/cobol1
/tmp/gcc/bin/gcobol
/tmp/gcc/share/man/man1/gcobol.1
/tmp/gcc/share/man/man3/gcobol.3
/tmp/gcc/share/gcobol
/tmp/gcc/share/gcobol/udf
/tmp/gcc/share/gcobol/udf/stored-char-length.cbl
> - gcobol.3 is installed in the root dir, the man3dir macro is
> undefined.
fixed
> - The header files mentioned in gcobol.3 are not installed.
fixed
> libgcobol:
>
> - the patches are missing the regenerated toplevel Makefile.in
fixed
> - the shared library is underlinked. There are unresolved
> symbols against libm and libstdc++.
I don't understand. I understand what you mean, I think, but not how
it can be true and still work in our testing. How is it possible to have
unresolved symbols in libgcobol, and still have a useable library?
If you could explain what you're seeing and suggest a fix, I'll
address it right away.
> - The build uses plain CC for the build, not the _FOR_HOST
> and _FOR_TARGET macros passed from the toplevel make.
We followed the fortran model. Make-lang.in has, e.g.,
cobol1$(exeext): $(cobol1_OBJS) $(BACKEND) $(LIBDEPS) attribs.o
+$(LLINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) attribs.o -o
$@ \ $(cobol1_OBJS) $(BACKEND) $(LIBS) $(BACKENDLIBS)
At no point do we reference $(CC). What do we need to differently?
> - the library build is not ready for multilibs.
True. Work is in progress.
> - configure.ac has reference to a GC enabled variant, however
> there's nothing in the Makefile supporting that build.
Yes, and I'm utterly confused about GC. I have no use for it,
but it seemed to be a requirement. Guidance eagerly sought.
> A simple hello.cob builds, is correctly linked against the shared
> library and executes fine.
That is why I don't understand "underlinked". :-)
> Is there some cobol based open source project, which could be used
> for further testing?
Using our repository, https://gitlab.cobolworx.com/COBOLworx/gcc-cobol
$ make -C gcc/cobol/nist report
will fetch the NIST CCVS-85 archive, build and run it.
$ make -C gcc/cobol/tests test
will run the local tests
$ make -C gcc/cobol/UAT test
will run the autotest suite derived from GnuCOBOL.
In discussion Sunday night, Tobias suggested we might add the NIST
archive to our repository. I've been reluctant to do that because of
size, but he shrugged at my guess. Here it is in fact:
$ ls -lh nist/newcob.val*
-rw-rw-r-- 1 jklowden jklowden 27M Apr 24 2024 nist/newcob.val
-rw-rw-r-- 1 jklowden jklowden 4.3M Apr 24 2024 nist/newcob.val.Z
The code has neither license nor copyright notice.
There is also a User Guide, which I found invaluable. It bears a
copyright,
Copyright 1993
The National Computing Centre Limited All rights reserved.
To me, that's an Eben Moglen Question. CCVS funding came from the US
government, and the PDF I have came via the efforts of a kind
and talented librarian from the NIST publications. The United States
government does not copyright anything it publishes, and it published
this document. (I also doubt the National Computing Centre, which no
longer exists, would mind.) I would only hope that if we include the
code, we include the documentation, too.
$ ls -lh
Documents/Technology/Languages/Cobol/nist-ccvs-85-userguide.pdf
-rw-r--r--@ 2 jklowden staff 6.8M Apr 18 2022
Documents/Technology/Languages/Cobol/nist-ccvs-85-userguide.pdf
See also:
https://ntrl.ntis.gov/NTRL/dashboard/searchResults/titleDetail/PB89151310.xhtml
https://apps.dtic.mil/sti/tr/pdf/AD0711369.pdf
Like Magna Carta, the CVS-85 appears to have more than one version.
The above scan is substantially differerent from my copy, which I think
was OCR'd.
--jkl
