On 1/07/2011 5:11 PM, mona attariyan wrote:
> CFLAGS="-O0 -I/[PATH]/glibc-2.5.1-custom/prefix/include -static
Yeah, it's not as simple as that, because Pg expects to be dynamically
linked and to be able to dlopen() libraries and dlsym() resolve function
pointers from them at runtime.
> creating conversions ... FATAL: could not load library
> "/usr/local/pgsql/lib/ascii_and_mic.so":
> /usr/local/pgsql/lib/ascii_and_mic.so: undefined symbol: pg_ascii2mic
... like that. You'll have to modify Pg to statically link such required
libraries in, and add a new lookup method that can return function
pointers to the internal statically linked copies of the functions when
they're required.
> I'm using Postgres to evaluate a research tool and the tool doesn't work
> with dynamic libraries. That's why I need to compile it statically.
OK, so you're not trying to embed Pg into an application or make it run
from a single executable. You just need "postgres", initdb, etc to each
be a statically linked executable. That's good; some people who ask that
sort of thing are angling for embedding it in an app, and it really
won't work.
For your purposes, you'll have to modify PostgreSQL to support being
built statically. It *expects* to be able to dlopen() libraries at
runtime, and those libraries often expect to be able to resolve symbols
from the postgres executable they're being linked into. This won't work
when it's a static binary. You'll have to figure out which libraries
each Pg executable needs during its lifetime, statically link them in as
well, and modify postgresql to know which libraries are linked in at
startup so it doesn't try to dlopen() them.
You can probably get Pg to use static copies of libraries it normally
dlopen()s by building mappings of library names to structs full of
function pointers that you return instead of the usual dlysm()'d
function pointer from a dlopen()'d library. If you do it that way, the
rest of Pg might not even need to know it's not truly dynamically
loading things.
--
Craig Ringer
