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-patched?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 > >
