> -----Original Message----- > From: Matthias Klose <d...@debian.org> > Sent: Tuesday, December 17, 2024 04:26 > To: Joseph Myers <josmy...@redhat.com> > Cc: gcc-patches@gcc.gnu.org; James K. Lowden <jklow...@schemamania.org> > Subject: Re: The COBOL front end, in 8 notes + toplevel patch > > On 17.12.24 00:58, Joseph Myers wrote: > > On Mon, 16 Dec 2024, Matthias Klose wrote: > > > >> On 14.12.24 15:38, Matthias Klose wrote: > >>> I tried to use the patches to build binary packages for Debian. > >>> Found some > >>> issues: > >> > >> tried to build libgcobol on more architectures, please find the > >> attached patch to disable building libgcobol on some architectures. > > > > Enabling on x86_64-*-linux* and disabling on i?86-*-linux* is > > inherently suspect since the difference between those is only about > > what the default multilib is, and says nothing about the multilib used > > for a particular compilation of libgcobol. (Of course we first need > > to fix multilib support for libgcobol if that isn't working correctly > > - all target libraries in GCC need proper multilib support.) > > > > why is this suspect? looking at libtsan and libhwasan, these are only > built for the 64bit variant, not for 32 and x32. > > Matthias
Matthias, we've put your suggested configure patches into place. And now I am exploring exactly the issue you mention here. The -m32 compilation on a x86_64 platform is failing, because the -m32 header files don't know anything about the __int128 declarations we're using. I've been looking, and I'll continue to look, but if you can point me in the direction of suppressing libgcobol compilations for -m32 and -m32x, you might save me a lot of reverse engineering. Thanks! Bob Dubner
