Re: Configuration and build clean-up

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Configuration and build clean-up
Date: 2000-05-30 14:22:39
Message-ID: 1774.959696559@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <e99re41(at)DoCS(dot)UU(dot)SE> writes:
>> I didn't notice anything about libtool in your list of items,

> The problem with libtool is this: it can't handle multiple languages at
> once. That means that you'd have to build libpq and libpq++ with
> sufficiently similar compilers.

Hmm. The one thing that we really need libtool for is to deal with
cross-shlib dependencies --- eg, arranging for libpq.so to be pulled
in if libpq++.so is loaded. (Right now, at least on my platform,
this doesn't work... the client app has to mention both at link time.)
I think we could assume that all the files in any one shlib are compiled
with the same compiler; is that enough, or does it still fall over?

The main place where I'm concerned about "only one compiler" is in pltcl
and plperl. We have found that the most reliable way to build those is
with the compiler and switches that were used to build Tcl and Perl
respectively, not with the compiler/switches being used for the main
Postgres build. One of the bits we have painstakingly got right is to
make this actually work (last time I tried, I could build these with
HP's cc whilst Postgres was configured with gcc or vice versa). The
simplest answer for those two might be to leave well enough alone.
There's no real reason to libtoolize them that I can see, nor to try
to fold them into a unified Postgres build environment.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Matthias Urlichs 2000-05-30 14:31:35 Re: [HACKERS] Re: 7.0 weirdness
Previous Message Jeff MacDonald 2000-05-30 14:10:24 Re: 7.0 weirdness