questions about porting postgresql to older operating system

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

questions about porting postgresql to older operating system

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


Reply | Threaded
Open this post in threaded view
|

Re: questions about porting postgresql to older operating system

Tom Lane-2
Tim Kelly <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: questions about porting postgresql to older operating system

Heikki Linnakangas
On 14/01/2021 20:18, Tom Lane wrote:
> Tim Kelly <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: questions about porting postgresql to older operating system

Tom Lane-2
Heikki Linnakangas <[hidden email]> 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