Thread: 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 ordirectory 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@dylex.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@dylex.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