Thread: questions about porting postgresql to older operating system

Hello,
I am working with an old version of an open source operating system.  I 
have long since forked from the main development and am not going back. 
  I have built my own toolchain, which does not include GNU's make or 
any other gnutils (except nano).  The OS is also not p-thread compliant 
(or MP-aware).  All libraries are statically linked.  I am following the 
adage "if you want something done a certain way, do it yourself," which 
I heard all-too-often before I did.

I am attempting to port postgresql-9.6.20 to this environment.  I've 
made it through various pitfalls in configure, but as I get closer to 
actually compiling, I'm wondering about the pitfalls ahead.

I had to run --disable-thread-safety, since there is not pthread 
support.  The configure process is failing at the time it needs to link

config.status: linking ./src/backend/port/dynloader/(removed).c to 
src/backend/port/dynloader.c
config.status: error: ./src/backend/port/dynloader/(removed).c: file not 
found

There is no dynamic linking or loading with this operating system.

There was no template for this operating system, so I added one.  I am 
emailing the address given in configure with my questions.

1) Starting with gmake, what specific functionality is required that can 
not be duplicated with manually crafting Makefiles?

2a) Can postgresql run without pthread support?
2b) If no, is there an older version that would run? (I need some 
functionality introduced in 8.x.)

3) Can postgresql still work without dynamic loading support?


Thank you,
tim

-- 
"I ain't gonna play Sun City."
    -- (Little) Steven Van Vandt/Artists United Against Apartheid

Tim Kelly <gtkelly@dialectronics.com> writes:
> 1) Starting with gmake, what specific functionality is required that can 
> not be duplicated with manually crafting Makefiles?

We've never worried about building with non-GNU make.  If you really want
to translate all of the Makefiles to old-style make syntax, it might be
possible, but it sure seems like a lot of make-work (pun intended).

> 2a) Can postgresql run without pthread support?

Definitely; we still have at least one buildfarm animal without that.

> 3) Can postgresql still work without dynamic loading support?

mmm ... in principle yes, but you'll lose one heck of a lot of
functionality that's implemented in extension modules.  Possibly
that could be worked around by deciding which extensions you need
and statically binding them into the backend executable.  Again,
that's not a case we've worried about for the last twenty years
or so, so there's likely to be some pain there.

            regards, tom lane

On 14/01/2021 20:18, Tom Lane wrote:
> Tim Kelly <gtkelly@dialectronics.com> writes >> 3) Can postgresql still work without dynamic loading support?
> 
> mmm ... in principle yes, but you'll lose one heck of a lot of
> functionality that's implemented in extension modules.  Possibly
> that could be worked around by deciding which extensions you need
> and statically binding them into the backend executable.  Again,
> that's not a case we've worried about for the last twenty years
> or so, so there's likely to be some pain there.

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

It would be cool if that worked.

- Heikki

Heikki Linnakangas <hlinnaka@iki.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