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. Thanks, Richard. > --jkl >
