'configure --disable-shared' and 'make check'
I notice that when I run 'make check' on a
statically linked HEAD, it fails during
'createlang' with
============== installing plpgsql ==============
ERROR: could not access file "$libdir/plpgsql": No such file or
directory
command failed:
"/postgres/cvs/pgsql/src/test/regress/./tmp_check/install//magwien/postg
res-8.2.a/bin/psql" -X -c "CREATE LANGUAGE \"plpgsql\"" "regression"
This is not a problem of the regression test
since I see the same behaviour when I do it manually.
Yours,
Laurenz Albe
Albe Laurenz wrote:
I notice that when I run 'make check' on a
statically linked HEAD, it fails during
'createlang' with
Because createlang relies on *dynamic* loading.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
Peter Eisentraut wrote:
I notice that when I run 'make check' on a
statically linked HEAD, it fails during
'createlang' withBecause createlang relies on *dynamic* loading.
So that is working as designed.
I interpret that as 'static builds for the database
server are not supported'. Ok by me.
Yours,
Laurenz Albe
Import Notes
Resolved by subject fallback
"Albe Laurenz" <all@adv.magwien.gv.at> writes:
Peter Eisentraut wrote:
Because createlang relies on *dynamic* loading.
So that is working as designed.
I interpret that as 'static builds for the database
server are not supported'. Ok by me.
Well, we're not supporting dynamically linked objects in a static build ;-)
It's at least theoretically possible that you could link selected PL
objects into a static backend build, but no one is particularly
interested in expending effort on it. There don't seem to be any
platforms anymore on which --disable-shared is actually important.
(Should we just get rid of it?)
regards, tom lane
Tom Lane wrote:
It's at least theoretically possible that you could link selected PL
objects into a static backend build, but no one is particularly
interested in expending effort on it. There don't seem to be any
platforms anymore on which --disable-shared is actually important.
(Should we just get rid of it?)
There is just one case where I think static linking might make some
sense: pg_dump for use during an upgrade. Unfortunately, at least on
Linux I found it to be close to impossible, as it uses some things that
are apparently only available dynamically - I forget the details.
So basically, I would say yes, let's just drop --disable-shared.
cheers
andrew
Am Donnerstag, 21. September 2006 16:02 schrieb Tom Lane:
There don't seem to be any
platforms anymore on which --disable-shared is actually important.
(Should we just get rid of it?)
IIRC, I added it in the past to test for static-only platforms like QNX. I
don't know if we plan to support such platforms in the future.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
Tom Lane wrote:
Well, we're not supporting dynamically linked objects in a static build ;-)
It's at least theoretically possible that you could link selected PL
objects into a static backend build, but no one is particularly
interested in expending effort on it. There don't seem to be any
platforms anymore on which --disable-shared is actually important.
(Should we just get rid of it?)
ISTR having to use --disable-shared to get a working profile-able build
on some platforms (might have been Solaris 8 with sun complier, but I'm
not really sure as it was a while ago).
Cheers
Mark