Building Extension on Linux fails with relocation error
I am new to PostgreSQL extension development and am currently working on
the *steampipe-postgres-fdw* project.
This is a *Foreign Data Wrapper (FDW) written in Go*, and while I have
successfully built it on Darwin systems, I am facing challenges when
building on Linux, particularly with *pgxs.mk <http://pgxs.mk>* against
PostgreSQL 14.
The issue arises with a Go module that is compiled into a .a archive file
using -buildmode=c-archive, leading to a *file size of approximately 393 MB*.
During the build process using *pgxs.mk <http://pgxs.mk>*, I encounter
several errors related to relocation and DWARF debug information, such as:
/usr/bin/ld: steampipe_postgres_fdw.a(go.o): relocation
R_AARCH64_ADR_PREL_PG_HI21 against symbol `type:string' which may bind
externally can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: DWARF error: line info data is bigger (0x65f0639) than the
space remaining in the section (0xe86ef9)
...
The log is for aarch64 - but I am getting similar errors for amd64 as well
Interestingly, the *build completes successfully when the .a file is
smaller* (around 100 MB).
As someone new to this area, I am a bit unclear on the following points:
- Best practices for compiling Go code for PostgreSQL FDWs on Linux
with *pgxs.mk
<http://pgxs.mk>*, especially regarding *-fPIC* and managing large
archive file sizes.
- Understanding and resolving the relocation and DWARF errors in the
context of PostgreSQL extension development.
- Any known issues or special considerations for building Go-based FDWs
for PostgreSQL 14 on Linux.
Any advice, insights, or pointers to relevant resources from the community
will be helpful.
Thank you for your time and assistance.
I am attaching a minimal piece of code to be able to reproduce - although
the *go toolchain* is required
Best regards,
Binaek Sarkar
Attachments:
Binaek Sarkar <binaek@turbot.com> writes:
The issue arises with a Go module that is compiled into a .a archive file
using -buildmode=c-archive, leading to a *file size of approximately 393 MB*.
I am not sure exactly what "-buildmode=c-archive" does, but it doesn't
sound like it is doing what you need. You need code that is built to
be dynamically relocatable, which as the error message suggests is
normally accomplished (with a C compiler) by specifying -fPIC.
You'll have to find out what is the equivalent incantation for Go;
but look for options for building shared libraries, not .a files.
Interestingly, the *build completes successfully when the .a file is
smaller* (around 100 MB).
Pure luck I suspect.
regards, tom lane
On 2023-12-22 10:31:14 -0500, Tom Lane wrote:
Binaek Sarkar <binaek@turbot.com> writes:
The issue arises with a Go module that is compiled into a .a archive file
using -buildmode=c-archive, leading to a *file size of approximately 393 MB*.
[...]
Interestingly, the *build completes successfully when the .a file is
smaller* (around 100 MB).Pure luck I suspect.
I seem to remember a 256MB limit for position independent code on x86.
The current man-page for GCC doesn't mention such a limit, though, so I
may be mistaken.
hp
--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
"Peter J. Holzer" <hjp-pgsql@hjp.at> writes:
On 2023-12-22 10:31:14 -0500, Tom Lane wrote:
Binaek Sarkar <binaek@turbot.com> writes:
Interestingly, the *build completes successfully when the .a file is
smaller* (around 100 MB).
Pure luck I suspect.
I seem to remember a 256MB limit for position independent code on x86.
The current man-page for GCC doesn't mention such a limit, though, so I
may be mistaken.
At least on x86, there is/was a shlib size boundary beyond which you
needed to generate different instructions with wider offset fields
in order to have position-independent code. Thus the difference
between -fpic and -fPIC. It's at least possible that the OP's Go
toolchain automatically uses -fpic, but I'm suspicious of that theory.
Usually you don't use either switch when building .a libraries.
regards, tom lane