Re: Build issues: "-static" builds resulting initdb problems

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Metin Ozisik" <metin(at)evincetek(dot)com>
Cc: pgsql-sql(at)postgresql(dot)org
Subject: Re: Build issues: "-static" builds resulting initdb problems
Date: 2005-04-30 16:03:02
Message-ID: 1829.1114876982@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

"Metin Ozisik" <metin(at)evincetek(dot)com> writes:
> The purpose of using static linking is to reduce dependencies to
> shared-libraries (dependencies to different types and versions of Linux), so
> an instance of postgreSQL, say built on Suse 9.0, would still work on
> Mandrake 10.1. Yes it gets a bit bulky and have a number of disadvantages
> over dynamic linking (on the plus side it would be a bit faster), however
> the main motivater is binary portability.

Well, both the PL languages and the character set conversion support are
*only* buildable as shared libraries right now. If you want to
statically link those into the main backend build, you can probably do
it, but it will take some nontrivial hacking.

In the meantime it would appear that your linker ignores the -E (export
all symbols) switch when -static is specified. I suppose it thinks
that not only don't you want any shared libraries now, but you won't
want any dynamically loaded libraries later. This is a Bad Idea;
complain to the linker hackers about it.

regards, tom lane

In response to

Responses

Browse pgsql-sql by date

  From Date Subject
Next Message Stephan Szabo 2005-04-30 16:41:42 Re: multi-column unique constraints with nullable columns
Previous Message Tornroth, Phill 2005-04-30 15:01:16 Re: multi-column unique constraints with nullable columns