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. 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 > > >
