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

Version: 8.0.2

Platforms: Linux, Fedora Core 2, Suse 9.2, Mandrake 10.1

Build time parameter: CFLAGS="-static" ./configure

results in a staticly linked binaries. (you are supposed to have static lib versions of readline, ncurses, etc, etc. of course)

However, conversion shared objects built in src/backend/utils/mb/conversion_procs still retain unresolved symbols, like: LocalToUtf, UtfToLocal, pg_ascii2mic, pg_mic2ascii (from src/backend/utils/mb/conv.c), as may be observed in:

for i in utf8*.so; do echo $i.....; nm $i | grep " U "; done

During initdb time, (I think initdb calls postgres and postgres attempts to load them.., regardless, both binaries are static), postgres' attempt to load conversion_procs fails with:

initdb --pgdata=/some/directory -L /some/dir/pgsql/share
....
loading pg_descriptions... ok
creating conversions ... FATAL: could not load library "../ascii_and_misc.so": ../../ascii_and_misc.so: undefined symbol: pg_mic2ascii
child process exited with exit code 1

I think a dynamic version of postgres would have supplied the unresolved symbols in shared-object load time, hence that wouldn't be an issue.

It seems undefined symbols in lib/utf8_and_*.so conversion procs (the four symbols listed above, from conv.c) needs to be resolved in link-time, so a "-static" build can work.

Regards,
-metin

"Metin Ozisik" <metin(at)evincetek(dot)com> writes:
> Build time parameter: CFLAGS="-static" ./configure

Is there a particular reason for you to be doing that?

> creating conversions ... FATAL: could not load library =
> "../ascii_and_misc.so": ../../ascii_and_misc.so: undefined symbol: =
> pg_mic2ascii

pg_mic2ascii is a function exported by the core backend. I suppose
that "-static" is somehow suppressing the visibility of that symbol
to the dynamically loaded library ascii_and_misc.so. I am not sure
whether this indicates a dynamic loader bug, or whether it's a case
of "so don't do that then" ... but in any case I don't think it's
a Postgres bug.

regards, tom lane

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.

Regards,
-metin

----- Original Message -----
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>
Sent: Friday, April 29, 2005 9:38 PM
Subject: Re: [SQL] Build issues: "-static" builds resulting initdb problems

> "Metin Ozisik" <metin(at)evincetek(dot)com> writes:
>> Build time parameter: CFLAGS="-static" ./configure
>
> Is there a particular reason for you to be doing that?
>
>> creating conversions ... FATAL: could not load library =
>> "../ascii_and_misc.so": ../../ascii_and_misc.so: undefined symbol: =
>> pg_mic2ascii
>
> pg_mic2ascii is a function exported by the core backend. I suppose
> that "-static" is somehow suppressing the visibility of that symbol
> to the dynamically loaded library ascii_and_misc.so. I am not sure
> whether this indicates a dynamic loader bug, or whether it's a case
> of "so don't do that then" ... but in any case I don't think it's
> a Postgres bug.
>
> regards, tom lane

"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

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.

Regards,
-metin

----- Original Message -----
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>
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),
>> 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