Re: questions about porting postgresql to older operating system
От | Heikki Linnakangas |
---|---|
Тема | Re: questions about porting postgresql to older operating system |
Дата | |
Msg-id | dbfc1cfa-1c15-ec22-d138-ddd12b9af5b9@iki.fi обсуждение исходный текст |
Ответ на | Re: questions about porting postgresql to older operating system (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: questions about porting postgresql to older operating system
|
Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: