Re: questions about porting postgresql to older operating system

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: Tim Kelly <gtkelly(at)dialectronics(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: questions about porting postgresql to older operating system
Date: 2021-01-14 18:44:19
Message-ID: 1419735.1610649859@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Heikki Linnakangas <hlinnaka(at)iki(dot)fi> writes:
> As it happens, I tried to build a completely static postgres binary
> yesterday. I was debugging the failure on sparc64, and I found out about
> user-space qemu, which can run binaries in binaries in a foreign
> architecture directly without a virtual machine. However, it requires
> that the binary is compiled statically. Cross-compiling a static
> postgres binary was surprisingly easy on Debian, but when I tried to run
> it, initdb failed because some library functions like getpweid() and
> gethostaddr() didn't work when linked statically.

That seems like an OS-level issue, not our fault.

> The cross-compiler
> warned about those, which was nice. I stubbed out a few of those library
> functions, but eventually it failed on a call to dlopen(). That's where
> I gave up.

Yeah, initdb is going to try to open the shared libraries for plpgsql and
all of the encoding-conversion modules (and maybe other stuff, but
that's all I can think of offhand). For an initial porting attempt,
it might be enough to cut out the parts of the bootstrap script that
create the default conversions and the plpgsql extension. It's hard
to believe you won't want plpgsql before long though.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Amit Kapila 2021-01-15 03:59:14 Re: BUG #16812: Logical decoding error
Previous Message Alvaro Herrera 2021-01-14 18:39:00 Re: BUG #16577: Segfault on altering a table located in a dropped tablespace