Thread: Configure problem when cross-compiling PostgreSQL 16.1

Hi all,

I was trying to cross-compile PostgreSQL 16.1 using Buildroot which worked fine
until I executed "initdb" on my target device, where I faced the following error:

2023-12-06 07:10:18.568 UTC [31] FATAL:  could not load library 
"/usr/lib/postgresql/dict_snowball.so": /usr/lib/postgresql/dict_snowball.so: 
undefined symbol: CurrentMemoryContext

It turned out that the "postgres" binary was missing the symbol
"CurrentMemoryContext" because the configure script assumed that my toolchain's
(GCC 9.4) linker does not support "--export-dynamic", although it supports it.

I had a quick look at the configure script where the following lines peeked my
interest:

if test "$cross_compiling" = yes; then :
   pgac_cv_prog_cc_LDFLAGS_EX_BE__Wl___export_dynamic="assuming no"

Apparently when cross-compiling the linker is automatically assumed to not
understand "--export-dynamic", leading to aforementioned problem on my end.

A workaround of mine is to override
pgac_cv_prog_cc_LDFLAGS_EX_BE__Wl___export_dynamic with "yes", which makes
everything work as expected.

There is also at least one additional linker flag "--as-needed" that is not
being used when cross-compiling. Is this a bug or am I misunderstanding the
implications that PostgreSQL has when "$cross_compiling=yes"?

Best regards,
Dominik

Dominik Michael Rauh <dmrauh@posteo.de> writes:
> Apparently when cross-compiling the linker is automatically assumed to not
> understand "--export-dynamic", leading to aforementioned problem on my end.
> ...
> There is also at least one additional linker flag "--as-needed" that is not
> being used when cross-compiling. Is this a bug or am I misunderstanding the
> implications that PostgreSQL has when "$cross_compiling=yes"?

Cross-compiling isn't really a supported thing, because there's too
much stuff we can't find out about the target system in that case.
If it works for you, great, but if it doesn't we're unlikely to put
a lot of effort into fixing it.  You might be able to manually
correct whatever mistaken assumptions configure made (by editing
its output files).  It's hard to see how that could be automated
though.

            regards, tom lane