Обсуждение: 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