Postgres Pro
Downloads
Home   >   mailing lists

Thread: Building Extension on Linux fails with relocation error

Building Extension on Linux fails with relocation error

From
Binaek Sarkar
Date:
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 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, 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, 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
Attachment

Re: Building Extension on Linux fails with relocation error

From
Tom Lane
Date:
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

Re: Building Extension on Linux fails with relocation error

From
"Peter J. Holzer"
Date:
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!"
Attachment

Re: Building Extension on Linux fails with relocation error

From
Tom Lane
Date:
"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