Re: Build problems

Yesterday's snapshot couldn't be compiled from a separate build
directory, and after configure --without-docdir ... make install failed,
because it tried to mkdir /postgresql/html.

The enclosed patch fixes these problems, at least for me.

Servus
Manfred

Manfred Koizar <mkoi-pg(at)aon(dot)at> writes:
> Yesterday's snapshot couldn't be compiled from a separate build
> directory, and after configure --without-docdir ... make install failed,
> because it tried to mkdir /postgresql/html.
> The enclosed patch fixes these problems, at least for me.

The src/timezone issue is reported and fixed already. I'm not quite
sure what --without-docdir should mean ... if it's not a complete no-op
it seems like it ought to specify not installing docs at all. But your
proposed patch doesn't do either of those. What have you got in mind
there? And I don't understand the point of your proposed change in
src/bin/psql/Makefile at all. Please elaborate.

regards, tom lane

Manfred Koizar <mkoi-pg(at)aon(dot)at> writes:
> On Sun, 23 May 2004 02:39:41 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I'm not quite
>> sure what --without-docdir should mean ... if it's not a complete no-op
>> it seems like it ought to specify not installing docs at all.

> --without-docdir do not install the documentation

> In doc/Makefile we have:
> ...
> ifneq ($(wildcard $(srcdir)/postgres.tar.gz),)
> ifneq (,$(docdir))
> found_html := yes
> endif
> endif

Okay, I see: this code is using docdir = empty to represent
--without-docdir, so we have to maintain that state in Makefile.global.
Got it now. But I wonder how much Peter could have tested
--without-docdir when he added it recently, because AFAICS it could
not have worked at all. The code to add /postgresql to docdir has
been there right along.

> src/bin/psql/psqlscan.c couldn't be compiled, it complained about
> several missing .h files.

Hmph. Works for me. Possibly a compiler-specific issue?

regards, tom lane

Manfred Koizar <mkoi-pg(at)aon(dot)at> writes:
> Here is what I get without that change:

> gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations
> -I/m/u2/home/fred/pgsrc/SNAP/tst04a/src/interfaces/libpq
> -I../../../src/include -I/m/u2/home/fred/pgsrc/SNAP/tst04a/src/include
> -D_GNU_SOURCE -DFRONTEND -c -o psqlscan.o
> /m/u2/home/fred/pgsrc/SNAP/tst04a/src/bin/psql/psqlscan.c -MMD
> psqlscan.l:40: psqlscan.h: No such file or directory
> psqlscan.l:46: common.h: No such file or directory
> psqlscan.l:47: settings.h: No such file or directory
> psqlscan.l:48: variables.h: No such file or directory
> make[3]: *** [psqlscan.o] Error 1

This seems extremely odd. Why would only psqlscan.c fail this way?
All the other .c files in src/bin/psql include these same headers in
the same way. And why does it fail for you but not for me, when we're
both using gcc?

The reason that a -I$(srcdir) should not be necessary is that gcc is
defined to automatically search the directory that the current input
file came from. You can find this mentioned in passing in the
documentation of the -I- command line option; apparently it's
sufficiently standard behavior that the gcc authors felt no need to say
it more prominently. I do find the same behavior defined explicitly in
the man page for HPUX's cpp:

-Idir Change the algorithm for searching for #include files
whose names do not begin with / to look in dir before
looking in the directories on the standard list. Thus,
#include files whose names are enclosed in double
quotes ("") are searched for first in the directory of
the file containing the #include line, then in
directories named in -I options in left-to-right order,
and last in directories on a standard list. For
#include files whose names are enclosed in angle
brackets (<>), the directory of the file containing the
#include line is not searched. However, directory dir
is still searched.

I think the actual problem is someplace else. Maybe your version of
flex is doing something weird when it generates psqlscan.c? What do
the #line directives look like in that file?

regards, tom lane

Manfred Koizar <mkoi-pg(at)aon(dot)at> writes:
> On Sun, 23 May 2004 11:40:29 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> both using gcc?

> Mine is quite old:
> $ gcc --version
> 2.7.2.1

Man, that's ancient. What we're probably looking at here is a bug in
the #include search algorithm in that version of gcc. How do you feel
about upgrading? I thought I was being a troglodyte by still running
2.95.3 ...

regards, tom lane

On Sun, 23 May 2004 13:16:49 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> $ gcc --version
>> 2.7.2.1
>
>Man, that's ancient.

Don't say that before you have seen my bike :-)

>How do you feel about upgrading?

This is on my notebook. I'm a little afraid of changing major parts of
the system. Once I tried to upgrade to gcc 3.0, but the build failed.
Maybe I should have upgraded to 2.95 first?

But I promise to test on a more modern system next time before I report
a build problem.

> I thought I was being a troglodyte by still running 2.95.3 ...

Troglodyte. Come on. I'm just a bit conservative ...

Servus
Manfred