Re: configure gaps

While trying to build PostgreSQL 9.0 on a machine where the SA had
omitted to install a lot of the required packages, I noticed a couple of
cases where configure passed but the build failed due to missing pieces
in the toolset.

Specifically, a) when python was installed but python-devel was not,
configure passed by the compile for python failed quite miserably, and
b) with gettext installed but not gettext-tools (and in particular
xgettext was missing), the NLS stuff failed.

I'm, not sure if this is worth fixing, but it seemed worth mentioning.
ISTM that if we pass configure, we should be able to assume that the
requisite build tools, libraries, include files etc. are present.

cheers

andrew

On Sat, Oct 2, 2010 at 10:01 AM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> I'm, not sure if this is worth fixing, but it seemed worth mentioning. ISTM
> that if we pass configure, we should be able to assume that the requisite
> build tools, libraries, include files etc. are present.

<trolling>
One of the things I really like about drizzle is if there a missing
dependency it will explicitly tell you what you are missing and where
to go find it for popular platforms.

Not being able to easily build is a barrier to entry. Does pg want those?
</trolling>

--
Rob Wultsch
wultsch(at)gmail(dot)com

On lör, 2010-10-02 at 13:01 -0400, Andrew Dunstan wrote:
> Specifically, a) when python was installed but python-devel was not,
> configure passed by the compile for python failed quite miserably, and

Yeah. Same is true if libperl-dev or similar is not installed.

> b) with gettext installed but not gettext-tools (and in particular
> xgettext was missing), the NLS stuff failed.

xgettext is not required for the build.

> ISTM that if we pass configure, we should be able to assume that the
> requisite build tools, libraries, include files etc. are present.

Technically, the primary purpose of configure is to (a) record the
user's configuration choices, and (b) set up substitutions for necessary
features that the OS does not provide. It should not be the place that
is forecasting the errors that the actual build tools might encounter.

That said, some gentle tweaks to improve user-friendliness might not be
wrong.

Rob Wultsch <wultsch(at)gmail(dot)com> writes:
> One of the things I really like about drizzle is if there a missing
> dependency it will explicitly tell you what you are missing and where
> to go find it for popular platforms.

Choose your platform wisely. Then, apt-get build-dep postgresql-9.0 :)

Regards,
--
dim

On 10/02/2010 01:35 PM, Peter Eisentraut wrote:
>
>> b) with gettext installed but not gettext-tools (and in particular
>> xgettext was missing), the NLS stuff failed.
> xgettext is not required for the build.

here is the tail of my make log with gettext-tools uninstalled (platform
is SLES 11 SP1):

make -C backend all
make[2]: Entering directory `/usr/local/src/pg_9_0/src/backend'
msgfmt -o po/de.mo po/de.po
You don't have 'xgettext'.
make[2]: *** [po/de.mo] Error 1
make[2]: *** Deleting file `po/de.mo'
make[2]: Leaving directory `/usr/local/src/pg_9_0/src/backend'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/usr/local/src/pg_9_0/src'
make: *** [all] Error 2

cheers

andrew

On 10/02/2010 02:31 PM, Dimitri Fontaine wrote:
> Rob Wultsch<wultsch(at)gmail(dot)com> writes:
>> One of the things I really like about drizzle is if there a missing
>> dependency it will explicitly tell you what you are missing and where
>> to go find it for popular platforms.
> Choose your platform wisely. Then, apt-get build-dep postgresql-9.0 :)

I have no choice. This is a client's platform, not mine.

cheers

andrew

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> On 10/02/2010 01:35 PM, Peter Eisentraut wrote:
>> xgettext is not required for the build.

> here is the tail of my make log with gettext-tools uninstalled (platform
> is SLES 11 SP1):

> make -C backend all
> make[2]: Entering directory `/usr/local/src/pg_9_0/src/backend'
> msgfmt -o po/de.mo po/de.po
> You don't have 'xgettext'.
> make[2]: *** [po/de.mo] Error 1

It seems to me that this indicates brain death on the part of the SLES
packager. Surely if msgfmt requires xgettext to work in his build, they
should be in the same subpackage, or else the one containing msgfmt
ought to require the one containing xgettext.

configure checks whether msgfmt is available; I think that its
responsibility stops there. We can't predict every reason why the
program might work or not at runtime.

regards, tom lane

I wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> make -C backend all
>> make[2]: Entering directory `/usr/local/src/pg_9_0/src/backend'
>> msgfmt -o po/de.mo po/de.po
>> You don't have 'xgettext'.
>> make[2]: *** [po/de.mo] Error 1

> It seems to me that this indicates brain death on the part of the SLES
> packager. Surely if msgfmt requires xgettext to work in his build, they
> should be in the same subpackage, or else the one containing msgfmt
> ought to require the one containing xgettext.

Wait a minute ... I was supposing that msgfmt was trying to invoke
xgettext, but now I notice that that exact message wording is in our
nls-global.mk. Is it possible that your build is trying to rebuild the
.pot files for some reason (maybe a timestamp skew issue)?

regards, tom lane

On lör, 2010-10-02 at 16:43 -0400, Andrew Dunstan wrote:
>
>
> On 10/02/2010 01:35 PM, Peter Eisentraut wrote:
> >
> > > b) with gettext installed but not gettext-tools (and in particular
> > > xgettext was missing), the NLS stuff failed.
> > xgettext is not required for the build.
>
> here is the tail of my make log with gettext-tools uninstalled
> (platform is SLES 11 SP1):
>
> make -C backend all
> make[2]: Entering directory
> `/usr/local/src/pg_9_0/src/backend'
> msgfmt -o po/de.mo po/de.po
> You don't have 'xgettext'.
> make[2]: *** [po/de.mo] Error 1
> make[2]: *** Deleting file `po/de.mo'
> make[2]: Leaving directory `/usr/local/src/pg_9_0/src/backend'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory `/usr/local/src/pg_9_0/src'
> make: *** [all] Error 2

Actually, it turns out the handling of nls-global.mk for missing
xgettext has been broken since revision 1.

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Actually, it turns out the handling of nls-global.mk for missing
> xgettext has been broken since revision 1.

Ooohh ... the ifdef's are in the wrong place, aren't they.

Maybe it would be better to use the "missing" script for xgettext
and drop the ifdefs?

regards, tom lane

On 10/02/2010 01:35 PM, Peter Eisentraut wrote:
> On lör, 2010-10-02 at 13:01 -0400, Andrew Dunstan wrote:
>> Specifically, a) when python was installed but python-devel was not,
>> configure passed by the compile for python failed quite miserably, and
> Yeah. Same is true if libperl-dev or similar is not installed.

No, actually configure pretty much catches this.

I propose that we add the following test for this case:

AC_CHECK_HEADER(Python.h, [], [AC_MSG_ERROR([header file <Python.h>
is required for Python])])

cheers

andrew

On tis, 2010-10-05 at 11:13 -0400, Andrew Dunstan wrote:
> > > Specifically, a) when python was installed but python-devel was not,
> > > configure passed by the compile for python failed quite miserably, and
> > Yeah. Same is true if libperl-dev or similar is not installed.
>
> No, actually configure pretty much catches this.

Not on my system.

gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing
-fwrapv -g -fpic -shared -o plperl.so plperl.o SPI.o Util.o
-L../../../src/port -Wl,--as-needed
-Wl,-rpath,'/usr/lib/perl/5.10/CORE',--enable-new-dtags
-fstack-protector -L/usr/local/lib -L/usr/lib/perl/5.10/CORE -lperl
-ldl -lm -lpthread -lc -lcrypt
/usr/bin/ld.bfd.real: cannot find -lperl
collect2: ld returned 1 exit status

On 10/05/2010 11:37 AM, Peter Eisentraut wrote:
> On tis, 2010-10-05 at 11:13 -0400, Andrew Dunstan wrote:
>>>> Specifically, a) when python was installed but python-devel was not,
>>>> configure passed by the compile for python failed quite miserably, and
>>> Yeah. Same is true if libperl-dev or similar is not installed.
>> No, actually configure pretty much catches this.
> Not on my system.
>
> gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
> -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing
> -fwrapv -g -fpic -shared -o plperl.so plperl.o SPI.o Util.o
> -L../../../src/port -Wl,--as-needed
> -Wl,-rpath,'/usr/lib/perl/5.10/CORE',--enable-new-dtags
> -fstack-protector -L/usr/local/lib -L/usr/lib/perl/5.10/CORE -lperl
> -ldl -lm -lpthread -lc -lcrypt
> /usr/bin/ld.bfd.real: cannot find -lperl
> collect2: ld returned 1 exit status

OK, then we should fix that too.

cheers

andrew

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> I propose that we add the following test for this case:

> AC_CHECK_HEADER(Python.h, [], [AC_MSG_ERROR([header file <Python.h>
> is required for Python])])

You'd need to pay attention to python_includespec, but otherwise seems
reasonable.

regards, tom lane

Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> > I propose that we add the following test for this case:
>
> > AC_CHECK_HEADER(Python.h, [], [AC_MSG_ERROR([header file <Python.h>
> > is required for Python])])
>
> You'd need to pay attention to python_includespec, but otherwise seems
> reasonable.

Did this get done? If so, I don't see it.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

On 02/21/2011 09:33 PM, Bruce Momjian wrote:
> Tom Lane wrote:
>> Andrew Dunstan<andrew(at)dunslane(dot)net> writes:
>>> I propose that we add the following test for this case:
>>> AC_CHECK_HEADER(Python.h, [], [AC_MSG_ERROR([header file<Python.h>
>>> is required for Python])])
>> You'd need to pay attention to python_includespec, but otherwise seems
>> reasonable.
> Did this get done? If so, I don't see it.

Oh, no. It skipped my TODO list. I'll try to get it done in the next day
or so.

cheers

andrew

Andrew Dunstan wrote:
>
>
> On 02/21/2011 09:33 PM, Bruce Momjian wrote:
> > Tom Lane wrote:
> >> Andrew Dunstan<andrew(at)dunslane(dot)net> writes:
> >>> I propose that we add the following test for this case:
> >>> AC_CHECK_HEADER(Python.h, [], [AC_MSG_ERROR([header file<Python.h>
> >>> is required for Python])])
> >> You'd need to pay attention to python_includespec, but otherwise seems
> >> reasonable.
> > Did this get done? If so, I don't see it.
>
> Oh, no. It skipped my TODO list. I'll try to get it done in the next day
> or so.

I have added this to the 9.1 open items list:

http://wiki.postgresql.org/wiki/PostgreSQL_9.1_Open_Items#Code_Issues

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Andrew Dunstan wrote:
>>
>>
>> On 02/21/2011 09:33 PM, Bruce Momjian wrote:
> Tom Lane wrote:
> Andrew Dunstan<andrew(at)dunslane(dot)net> writes:
> I propose that we add the following test for this case:
> AC_CHECK_HEADER(Python.h, [], [AC_MSG_ERROR([header file<Python.h>
> is required for Python])])
> You'd need to pay attention to python_includespec, but otherwise seems
> reasonable.
> Did this get done? If so, I don't see it.
>>
>> Oh, no. It skipped my TODO list. I'll try to get it done in the next day
>> or so.

> I have added this to the 9.1 open items list:

> http://wiki.postgresql.org/wiki/PostgreSQL_9.1_Open_Items#Code_Issues

Waste of time, because that got done some time ago.

regards, tom lane

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > Andrew Dunstan wrote:
> >>
> >>
> >> On 02/21/2011 09:33 PM, Bruce Momjian wrote:
> > Tom Lane wrote:
> > Andrew Dunstan<andrew(at)dunslane(dot)net> writes:
> > I propose that we add the following test for this case:
> > AC_CHECK_HEADER(Python.h, [], [AC_MSG_ERROR([header file<Python.h>
> > is required for Python])])
> > You'd need to pay attention to python_includespec, but otherwise seems
> > reasonable.
> > Did this get done? If so, I don't see it.
> >>
> >> Oh, no. It skipped my TODO list. I'll try to get it done in the next day
> >> or so.
>
> > I have added this to the 9.1 open items list:
>
> > http://wiki.postgresql.org/wiki/PostgreSQL_9.1_Open_Items#Code_Issues
>
> Waste of time, because that got done some time ago.

OK, thanks. Removed.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

On 03/10/2011 03:14 PM, Bruce Momjian wrote:
>>> Did this get done? If so, I don't see it.
>> Oh, no. It skipped my TODO list. I'll try to get it done in the next day
>> or so.
> I have added this to the 9.1 open items list:
>
> http://wiki.postgresql.org/wiki/PostgreSQL_9.1_Open_Items#Code_Issues

It's been done. See
<http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=42e5223648e7e56f8041bed329929dbd5529ea92>

cheers

andrew