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
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 |