BUG #17898: Build failure when strip is LLVM's version
The following bug has been logged on the website:
Bug reference: 17898
Logged by: Ed Maste
Email address: emaste@freebsd.org
PostgreSQL version: 13.10
Operating system: FreeBSD
Description:
In FreeBSD we are experimenting with the use of LLVM's binutils-like tools,
including installing llvm-objcopy as strip. When this is done PostgreSQL
fails to build, with error
====
STRIPPROG='strip -x' /bin/sh ../../../config/install-sh -c -m 644 -s libpq.a
'/wrkdirs/usr/ports/databases/postgresql13-client/work/stage/usr/local/lib/libpq.a'
strip: error:
'/wrkdirs/usr/ports/databases/postgresql13-client/work/stage/usr/local/lib/_inst.20299_':
not stripping symbol '.L.str' because it is named in a relocation
====
This occurs because llvm-objcopy is more strict, compared to GNU strip or
ELF Tool Chain strip. When -x is specified (i.e., discard all non-global
symbols) but the object to strip contains symbols that cannot be discarded
LLVM's strip emits an error. GNU and ELF Tool Chain strip instead just
retain the referenced non-global symbols.
Within the FreeBSD ports collection TCL and PostgreSQL are the only
significant software packages affected by this issue. TCL addressed this by
using --strip-unneeded instead of -x.
FreeBSD bug report:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270769
LLVM issue: https://github.com/llvm/llvm-project/issues/47468
TCL issue:
https://core.tcl-lang.org/tcl/tktview/718de2132f487cf29dfdd0be2b90fcc0107c2aa7
PG Bug reporting form <noreply@postgresql.org> writes:
In FreeBSD we are experimenting with the use of LLVM's binutils-like tools,
including installing llvm-objcopy as strip. When this is done PostgreSQL
fails to build, with error
Thanks for the report.
Within the FreeBSD ports collection TCL and PostgreSQL are the only
significant software packages affected by this issue. TCL addressed this by
using --strip-unneeded instead of -x.
We've done likewise [1]https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=a14afd3bdc21c0c56401fb8cb2fce74f4b7dc446.
regards, tom lane