Re: BUG #5665: catalog/schemapg.h: No such file or directory

I'm seeing this problem too, so I might be able to shed some light on it.

Here's exactly what I did:

> cd /usr/src/postgresql-9.0.2
> tar -xjvf postgresql-9.0.2.tar.bz2
> mv postgresql-9.0.2 src
> mkdir obj-x86_64
> cd obj-x86_64
> /usr/src/postgresql-9.0.2/src/configure '--prefix=/usr/local/postgresql-9.0.2' \
'--exec-prefix=/usr/local/postgresql-9.0.2' \
'--libdir=/usr/local/postgresql-9.0.2/lib64' \
'--sysconfdir=/usr/etc' \
'--localstatedir=/var' \
'--disable-nls' \
'--enable-integer-datetimes'
> make
...
make[4]: Entering directory `/loot/src/postgresql-9.0.2/obj-x86_64/src/backend/utils/cache'
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -I../../../../src/include -I/usr/src/postgresql-9.0.2/src/src/include -D_GNU_SOURCE -c -o relcache.o /usr/src/postgresql-9.0.2/src/src/backend/utils/cache/relcache.c
/usr/src/postgresql-9.0.2/src/src/backend/utils/cache/relcache.c:57:30: fatal error: catalog/schemapg.h: No such file or directory
compilation terminated.

> find /usr/src/postgresql-9.0.2 -name schemapg.h -ls
-rw-r--r-- 1 dylan src 14754 Dec 13 22:20 ./src/src/backend/catalog/schemapg.h
lrwxrwxrwx 1 dylan src 68 Jan 29 06:38 ./obj-x86_64/src/include/catalog/schemapg.h -> /loot/src/postgresql-9.0.2/obj-x86_64/src/backend/catalog/schemapg.h

> make -C /usr/src/postgresql-9.0.2/obj-x86_64/src/backend/catalog schemapg.h
make: `/usr/src/postgresql-9.0.2/src/src/backend/catalog/schemapg.h' is up to date.

> make -v
GNU Make 3.82

It looks like this is related to VPATH, in that make finds the distributed
schemapg.h when it goes to generate it in the obj directory, and so it's never
created there. Perhaps schemapg.h should not be distributed if it's
generated, or the symlink should point to srcdir instead of builddir.

Dylan Alex Simon <dylan(at)dylex(dot)net> writes:
> I'm seeing this problem too, so I might be able to shed some light on it.
> Here's exactly what I did:

>> cd /usr/src/postgresql-9.0.2
>> tar -xjvf postgresql-9.0.2.tar.bz2
>> mv postgresql-9.0.2 src
>> mkdir obj-x86_64
>> cd obj-x86_64
>> /usr/src/postgresql-9.0.2/src/configure '--prefix=/usr/local/postgresql-9.0.2' \
> '--exec-prefix=/usr/local/postgresql-9.0.2' \
> '--libdir=/usr/local/postgresql-9.0.2/lib64' \
> '--sysconfdir=/usr/etc' \
> '--localstatedir=/var' \
> '--disable-nls' \
> '--enable-integer-datetimes'
>> make

Hm. I can't replicate this at all. I followed your recipe (except for
starting in ~/tmp not /usr/src) and the make completed without error.
I see

$ pwd
/home/tgl/tmp/postgresql-9.0.2
$ find . -name schemapg.h -ls
1984573 16 -rw-r--r-- 1 tgl tgl 14754 Dec 13 22:20 ./src/src/backend/catalog/schemapg.h
2097841 0 lrwxrwxrwx 1 tgl tgl 65 Jan 29 18:25 ./obj-x86_64/src/include/catalog/schemapg.h -> /home/tgl/tmp/postgresql-9.0.2/src/src/backend/catalog/schemapg.h

As you can see, the symlink has the correct absolute path to the
schemapg.h file in the source tree. You're getting a wrong link:

> lrwxrwxrwx 1 dylan src 68 Jan 29 06:38 ./obj-x86_64/src/include/catalog/schemapg.h -> /loot/src/postgresql-9.0.2/obj-x86_64/src/backend/catalog/schemapg.h

I'm not sure about the "/loot" part (copy and paste-o?) but anyway it
seems to be pointing into the build tree not the source tree.

>> make -v
>> GNU Make 3.82

Mine is 3.81 (Fedora 13). Is it possible this is a bug introduced in
3.82? The symlink is made this way:

$(top_builddir)/src/include/catalog/schemapg.h: catalog/schemapg.h
prereqdir=`cd $(dir $<) >/dev/null && pwd` && \
cd $(dir $@) && rm -f $(notdir $@) && \
$(LN_S) "$$prereqdir/$(notdir $<)" .

so AFAICS the possibilities are that make is getting the wrong answer
for "dir $<" or that pwd is broken.

What platform are you on exactly?

regards, tom lane

I wrote:
> Dylan Alex Simon <dylan(at)dylex(dot)net> writes:
>> I'm seeing this problem too, so I might be able to shed some light on it.

> Hm. I can't replicate this at all.
> ...

>> GNU Make 3.82

> Mine is 3.81 (Fedora 13). Is it possible this is a bug introduced in
> 3.82? The symlink is made this way:

> $(top_builddir)/src/include/catalog/schemapg.h: catalog/schemapg.h
> prereqdir=`cd $(dir $<) >/dev/null && pwd` && \
> cd $(dir $@) && rm -f $(notdir $@) && \
> $(LN_S) "$$prereqdir/$(notdir $<)" .

Ah-hah: when I try it on Fedora 14 (with make 3.82), it fails just as
Dylan describes. Doing it manually in builddir/src/backend shows that
"dir $<" is indeed the culprit:

$ rm ../../src/include/catalog/schemapg.h
$ make ../../src/include/catalog/schemapg.h
make -C catalog schemapg.h
make[1]: Entering directory `/home/tgl/tmp/postgresql-9.0.2/obj-x86_64/src/backend/catalog'
make[1]: `/home/tgl/tmp/postgresql-9.0.2/src/src/backend/catalog/schemapg.h' is up to date.
make[1]: Leaving directory `/home/tgl/tmp/postgresql-9.0.2/obj-x86_64/src/backend/catalog'
prereqdir=`cd catalog/ >/dev/null && pwd` && \
cd ../../src/include/catalog/ && rm -f schemapg.h && \
ln -s "$prereqdir/schemapg.h" .
$ ls -l ../../src/include/catalog/schemapg.h
lrwxrwxrwx. 1 tgl tgl 72 Jan 30 13:03 ../../src/include/catalog/schemapg.h -> /home/tgl/tmp/postgresql-9.0.2/obj-x86_64/src/backend/catalog/schemapg.h

Now, this make rule looks exactly like the one for parser/gram.h, and
that's not misbehaving. The problem appears to be caused by the
other rule for schemapg.h:

# run this unconditionally to avoid needing to know its dependencies here:
submake-schemapg:
$(MAKE) -C catalog schemapg.h

.PHONY: submake-schemapg

catalog/schemapg.h: submake-schemapg

If I comment this out entirely, or change it to a simple rule

catalog/schemapg.h:
$(MAKE) -C catalog schemapg.h

then the symlink is built correctly. Apparently, the use of a phony
dependency causes make to decide that "catalog/schemapg.h" must refer to
a file in the build tree not the source tree.

I'm not sure whether the gmake boys will think this is a bug. It's
certainly a behavior change from pre-3.82 releases. In any case,
I think the rule for catalog/schemapg.h is a bit too cute (and even more
so in HEAD ... WTF is that "|" in there now?). We need to be less
bleeding edge here.

regards, tom lane