Correct. A static binary is perfectly capable of dynamic-loading shared
objects; therefore "-static" should not shadow "-E". I will forward this to
linker folks. In the meantime, if you guys can provide self-sufficient
conversion shared-objects by any chance in some future release perhaps, that
will be much appreciated.
----- Original Message -----
From: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Metin Ozisik" <metin(at)evincetek(dot)com>
Sent: Saturday, April 30, 2005 9:03 AM
Subject: Re: [SQL] Build issues: "-static" builds resulting initdb problems
> "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),
>> 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
pgsql-sql by date
|Next:||From: Cosimo Streppone||Date: 2005-04-30 22:10:30|
|Subject: pgtop, display PostgreSQL processes in `top' style|
|Previous:||From: Stephan Szabo||Date: 2005-04-30 16:41:42|
|Subject: Re: multi-column unique constraints with nullable columns|