On Sat, Mar 8, 2025 at 12:12 AM Robert Dubner <rdub...@symas.com> wrote:
>
> Richard and Jakub, and everybody else who has offered advice and help
>
> I trust you realize that your message means Jim and I are reaching the top
> of a mountain we've been climbing for several years now.
>
> This is very exciting.
>
> Thank you. Thank you very much.
During this I saw
index 10a42cb1dd7..8e666618ef1 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
...
+# user-defined functions for GCOBOL
+udfdir = $(datadir)/gcobol/udf
..
@@ -4031,7 +4035,9 @@ installdirs:
$(mkinstalldirs) $(DESTDIR)$(includedir)
$(mkinstalldirs) $(DESTDIR)$(infodir)
$(mkinstalldirs) $(DESTDIR)$(man1dir)
+ $(mkinstalldirs) $(DESTDIR)$(man3dir)
$(mkinstalldirs) $(DESTDIR)$(man7dir)
+ $(mkinstalldirs) $(DESTDIR)$(udfdir)
while generating man3dir is probably OK when not configuring COBOL
the udfdir creation looks spurious and is repeated(?) in cobol/Make-lang.in:
cobol.install-common: installdirs
$(INSTALL_PROGRAM) gcobol$(exeext) $(DESTDIR)$(bindir)/
$(INSTALL_PROGRAM) cobol1$(exeext) $(DESTDIR)$(libexecsubdir)/
$(INSTALL) -m 755 $(srcdir)/cobol/gcobc $(DESTDIR)$(bindir)/
mkdir -p $(DESTDIR)$(datadir)/gcobol/udf
$(INSTALL_DATA) $(srcdir)/cobol/udf/* $(DESTDIR)$(datadir)/gcobol/udf/
I don't know exactly what UDF is, but I'm going to prune the gcc/Makefile.in
UDF changes. Does that analysis look OK?
Building gcobol with GCC 7 shows
gcc/cobol/except.cc:285:70: sorry, unimplemented: non-trivial
designated initializers not supported
that needs to be sorted out (post-merge is OK).
I'm preparing a branch with squashed merged from cobol-patched and
will push that later
today to a branch on gcc.gnu.org git and tomorrow from there to trunk.
Richard.
>
> Bob Dubner
>
> > -----Original Message-----
> > From: Richard Biener <richard.guent...@gmail.com>
> > Sent: Friday, March 7, 2025 07:27
> > To: James K. Lowden <jklow...@schemamania.org>
> > Cc: Jakub Jelinek <ja...@redhat.com>; gcc-patches@gcc.gnu.org
> > Subject: Re: The COBOL front end, version 3, now in 14 easy pieces
> >
> > On Fri, Mar 7, 2025 at 11:34 AM Richard Biener
> > <richard.guent...@gmail.com> wrote:
> > >
> > > On Thu, Mar 6, 2025 at 11:50 PM James K. Lowden
> > > <jklow...@schemamania.org> wrote:
> > > >
> > > > On Wed, 5 Mar 2025 11:43:16 +0100
> > > > Richard Biener <richard.guent...@gmail.com> wrote:
> > > >
> > > > > > In short, despite not trying to support DESTDIR, we do anyway,
> > > > > > by happy accident. And we are now better informed.
> > > > >
> > > > > Thanks. Checking cobol-patched again I see
> > > >
> > > > Hi Richard,
> > > >
> > > > I have regenerated and force-pushed cobol-patched. It is now based
> > > > on
> > > >
> > > > commit 49ac89e03f2f171b401ac8b9d7c3cef72efbdc63
> > > > Author: Jakub Jelinek <ja...@redhat.com>
> > > > Date: Thu Mar 6 17:29:03 2025 +0100
> > > >
> > > > https://gitlab.cobolworx.com/COBOLworx/gcc-cobol/-/tree/cobol-patche
> > > > d?ref_type=heads
> > > >
> > > > There are still 15 patches. The texi file updates that I thought
> > > > would cause a problem merged cleanly. Yay, git.
> > > >
> > > > At your suggestion, we tested a bootstrap build with multilib.
> > > >
> > > > Our thanks to you and Jakub for your patience and guidance.
> > > >
> > > > The issues raised are addressed:
> > > >
> > > > - test for 32-bit code generation in the compiler instead of
> > > > checking for -m32 in gcobol.
> > > > - use GCC_WITH_TOOLEXECLIBDIR in libgcobol/configure.am
> > > > - support DESTDIR in libgcobol/Automake.am
> > > > - verify --enable-version-specific-runtime-libs
> > > >
> > > > Status of issues, with reference to email:
> > > >
> > > > On Wed, Mar 05, 2025 at 12:46:48PM +0100, Richard Biener wrote:
> > > > > and the installed compiler behaves as intended. I can trick -m32
> > > > > to
> > > > "work"
> > > > > by using the generic gcc driver:
> > > > >
> > > > > > ./install/gcc-cobol/usr/local/bin/gcc -x cobol t.cob -m32 -c
> > > >
> > > > Fixed by applying Jakub's suggestion,
> > > >
> > > > if (!targetm.scalar_mode_supported_p (TImode) ||
> > !float128_type_node)
> > > > sorry ("COBOL not supported in this configuration");
> > > >
> > > > $ /tmp/build-try/bin/gcobol -oo -m32 -ffixed-form
> > > > gcc/cobol/nist/NC/NC101A.cbl <built-in>: sorry, unimplemented: COBOL
> > > > requires a 64-bit configuration
> > > >
> > > > (I don't think "configuration" is the best nomenclature here, if
> > > > "configuration" is the product of the "configure" script.
> > > > Suggestions
> > > > welcome.)
> > >
> > > I think more to the point would be 'COBOL requires int128 and float128
> > support'
> > >
> > > > > > make install DESTDIR=/home/rguenther/install/gcc-cobol
> > > > > libtool: install: error: cannot install `libgcobol.la' to a
> > > > > directory
> > > >
> > > > Fixed by point-and-grunt comparison with libatomic. Observed
> > > >
> > > > + $(top_srcdir)/../config/toolexeclibdir.m4 \
> > > >
> > > > in libgcobol/Makefile.in.
> > > >
> > > > > ... aaand it fails: (../gcc-cobol/configure
> > > > > --enable-languages=cobol --disable-bootstrap
> > > > > --enable-checking=release
> > > > > --enable-version-specific-runtime-libs)
> > > >
> > > > Tested with that specific command line after applying above changes.
> > > > Observed "make install" works correctly.
> > >
> > > make install completes successfully but libgcobol does not end up in
> > > the expected place. I see
> > >
> > > ls install/gcc-cobol/usr/local/lib64/
> > > gcc libcc1.so libcc1.so.0.0.0 libgcobol.la libgcobol.so.1
> > > libcc1.la libcc1.so.0 libgcobol.a libgcobol.so
> > libgcobol.so.1.0.0
> > >
> > > (libcc1 is similarly broken), expected would be here:
> > >
> > > ls install/gcc-cobol/usr/local/lib64/gcc/x86_64-pc-linux-gnu/15.0.1/
> > > 32 libgomp.so.1 libssp.so.0
> > > crtbegin.o libgomp.so.1.0.0 libssp.so.0.0.0
> > > crtbeginS.o libgomp.spec libssp_nonshared.a
> > > crtbeginT.o libhwasan.a libssp_nonshared.la
> > > crtend.o libhwasan.la libstdc++.a
> > > ...
> > >
> > > I think this can be sorted out later for us poor users of
> > > --enable-version-specific-runtime-libs.
> >
> > We've quickly decided that we are ready-to-go for a merge from cobol-
> > patched.
> > The plan is to try doing this on Monday with Jakub doing the initial setup
> > so ChangeLog and pre-commit hooks are in place and I'll deal with picking
> > the rest from cobol-patched. I'm going to keep an extra eye so that
> > everything is in place, likely squashing or re-ordering revs to make sure
> > every rev we have will build.
> >
> > The remaining bits to address (if they are not already) are to put a
> > testsuite or instructions on testing in place, make sure user-level
> > documentation is in place and sort out issues people will inevitably run
> > into enabling COBOL on more hosts.
> >
> > It might be a good time for you to request git write access and as first
> > add yourself with an entry to the MAINTAINERS file under the 'Language
> > Front Ends Maintainers' section. You can list myself as sponsor for that.
> >
> > Thanks,
> > Richard.
> >
> > > Thanks,
> > > Richard.
> > >
> > > > --jkl
> > > >
