On Mon, 24 Feb 2025 14:51:27 +0100 Richard Biener <richard.guent...@gmail.com> wrote:
> > Our repository is > > > > https://gitlab.cobolworx.com/COBOLworx/gcc-cobol/ > > > > using branch > > > > cobol-stage > > > > I tested these patches using "git apply" to an unpublished branch > > "cobol-patched". > > I have now built the compiler from the (now published) cobol-patched > branch. > > On x86_64-linux and noticed the following issues: Hi Richard, I have regenerated and force-pushed cobol-patched. It is still based on 3e08a4ecea27c54fda90e8f58641b1986ad957e1 from February 4 because I wanted to maintain a consistent baseline. We will update our repository from master tomorow; the next set, if needed, will be from March 4. https://gitlab.cobolworx.com/COBOLworx/gcc-cobol/-/tree/cobol-patched?ref_type=heads There are now 15 patches, the last being the info documents. To remind, there have been changes to the texi files since our last update from master. These patches apply cleanly to master as of the above commit, but not to the current status. I think we have answered all issues raised: - Flex & Bison requirements are documented - gcobc is intentional - man pages install correctly - libgcobol installs to PREFIX/lib64 - nothing is written to the source tree unless requested - any and all variations of 32-bit are prevented - under "all" languages, gcobol is disabled except for x86_64 and aaarch64. - for --languages=cobol, gcobol will build for a 64-bit host and target. By far the hardest for us was the autotool work for libgcobol. My thanks to our comrades on IRC who helped me grope my way along. Details below, with reference to your message: > The toplevel configure script on the branch wasn't re-generated (duh), committed > %require "3.5.1" // 3.8.2 also works, but not 3.8.0 > ^^^^^^^ > > this requirement isn't documented documented. cobol-patched currently is missing updates to gcc/doc from master branch. Will update soon. During the build we write to gcc/cobol/charmaps-dupe.cc gcc/cobol/valconv-dupe.cc corrected > Installing the result via make install DESTDIR=/foo I see both a > 'gcobol' and a 'gcobc' program > being installed - is that intentional? yes, gcobc is an emulation script > I also see the gcobol.3 > manpage reside directly in /foo/gcobol.3 rather > than in the expected /foo/usr/local/man/.. corrected > Installing of libgcobol fails for me: corrected, with a caveat. libgcobol.so (etc) now installs in PREFIX/lib64 (previously PREFIX/lib). However IMO, the incantation: make install DESTDIR=/foo is invalid. The compiler's library search path is fixed when the compiler is built, based on configure options. Installing into an arbitrary directory cannot work; there is no opportunity then to alter the gcobol binary. > so the suppression seems incomplete? gcobol -m32 now produces an error message. The built compiler will not build 32-bit binaries, and libgcobol cannot be configured for 32-bit targets. With regard to 64-bit hosts and targets: 1. if --enable-languages is not used, gcobol is not built because it is not a default language. 2. if --enable-languages=all, gcobol is built only if the host and target are x86_64 or aarch64. We have not successfully built a cross-compiler (yet), but it's allowed. 3. if --enable-languages=cobol, gcobol will be built for any 64-bit host or target. The presumption is that the user has read the documented limitations. If he's working outside those bounds, we hope it's because he's hoping to move them. You mentioned, > The way to check is likely whether a mode for __int128 exists and is > supported. The C fronted does > > if (targetm.scalar_mode_supported_p (TImode)) > > it also checks float128_type_node, but I didn't find who initializes > that. We have not investigated that tweak yet. > > ./install/gcc-cobol/usr/local/bin/gcobol t.cob -m32 > > only fails during linking as we do build a 32bit binary but do not > find (the not built) 32bit runtime. corrected I am sorry this took as long as it did. We've been working on it night and day, and know a lot more about the build system now than we ever expected to. Kind regards, --jkl
