On 06.02.25 00:36, Robert Dubner wrote:
-----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.
have a look at libsanitizer/configure.tgt. The check for
test x$ac_cv_sizeof_void_p = x8
should work in a similar way.
Matthias
