Обсуждение: 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@dunslane.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@gmail.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@gmail.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
<br /><br /> On 10/02/2010 01:35 PM, Peter Eisentraut wrote: <blockquote cite="mid:1286040906.31996.11.camel@vanquo.pezone.net"type="cite"><br /><blockquote type="cite"><pre wrap="">b) with gettextinstalled but not gettext-tools (and in particular xgettext was missing), the NLS stuff failed. </pre></blockquote><pre wrap=""> xgettext is not required for the build. </pre></blockquote><br /> here is the tail of my make log with gettext-tools uninstalled (platform is SLES 11 SP1):<br /><br/><blockquote>make -C backend all<br /> make[2]: Entering directory `/usr/local/src/pg_9_0/src/backend'<br /> msgfmt-o po/de.mo po/de.po<br /> You don't have 'xgettext'.<br /> make[2]: *** [po/de.mo] Error 1<br /> make[2]: *** Deletingfile `po/de.mo'<br /> make[2]: Leaving directory `/usr/local/src/pg_9_0/src/backend'<br /> make[1]: *** [all] Error2<br /> make[1]: Leaving directory `/usr/local/src/pg_9_0/src'<br /> make: *** [all] Error 2<br /><br /></blockquote><br/> cheers<br /><br /> andrew<br />
On 10/02/2010 02:31 PM, Dimitri Fontaine wrote: > Rob Wultsch<wultsch@gmail.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@dunslane.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@dunslane.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@gmx.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
<br /><br /> On 10/02/2010 01:35 PM, Peter Eisentraut wrote: <blockquote cite="mid:1286040906.31996.11.camel@vanquo.pezone.net"type="cite"><pre wrap="">On lör, 2010-10-02 at 13:01 -0400, AndrewDunstan wrote: </pre><blockquote type="cite"><pre wrap="">Specifically, a) when python was installed but python-devel was not, configure passed by the compile for python failed quite miserably, and </pre></blockquote><pre wrap=""> Yeah. Same is true if libperl-dev or similar is not installed. </pre></blockquote><br /> No, actually configure pretty much catches this.<br /><br /> I propose that we add the followingtest for this case:<br /><br /><blockquote>AC_CHECK_HEADER(Python.h, [], [AC_MSG_ERROR([header file <Python.h>is required for Python])])<br /></blockquote><br /><br /> cheers<br /><br /> andrew<br />
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@dunslane.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@dunslane.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@momjian.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@dunslane.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@dunslane.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@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Bruce Momjian <bruce@momjian.us> writes: > Andrew Dunstan wrote: >> >> >> On 02/21/2011 09:33 PM, Bruce Momjian wrote: > Tom Lane wrote: > Andrew Dunstan<andrew@dunslane.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@momjian.us> writes: > > Andrew Dunstan wrote: > >> > >> > >> On 02/21/2011 09:33 PM, Bruce Momjian wrote: > > Tom Lane wrote: > > Andrew Dunstan<andrew@dunslane.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@momjian.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