possible inter-gcc-version incompatibility regarding fat objects

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: possible inter-gcc-version incompatibility regarding fat objects
Date: 2024-01-31 06:04:22
Message-ID: 20240131.150422.940846342629197768.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello.

I would like to share some information regarding a recent issue we
encoutered.

While compiling an extension against the RPM package
postgresql16-devel-16.1-2PGDG.rhel9.x86_64.rpm we faced a problem that
appears to be caused by the combination of LTO and constant
folding/propagation, leading to a SEGV. This crash didn't occur when
we gave --fno-lto instead of --flto=auto to the compiler.

To put this case briefly:
postgresql16-devel-16.1-2PGDG.rhel9.x86_64.rpm + gcc 11.3
=> building the extension completes but the binary may crash with SEGV
--fno-lto prevents this crash from occurring.

The PG package is built with gcc-11.4, and the compiler in our build
environment for the extension was gcc-11.3. A quick search suggests
that the LTO bytecode format was optimized in gcc-11.4. Conversely,
when we built the extension with postgresql-16-16.0 and gc-11.4, the
build fails. This failure seems to stem LTO binary format
incompatibility.

> Error: bad register name `%'
> Error: open CFI at the end of file; missing .cfi_endproc directive
> /usr/bin/ld: error: lto-wrapper failed

To put this case briefly:
postgresql16-devel-16.0-1PGDG.rhel9.x86_64.rpm + gcc 11.4
=> build failure regarding LTO

Given these issues, it seems there might be some issues with including
fat objects in the -devel package.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2024-01-31 06:08:58 Re: int4->bool test coverage
Previous Message Ashutosh Bapat 2024-01-31 05:58:07 Re: Incorrect cost for MergeAppend