Обсуждение: Where `gcc -MMD' puts .d files
Hi. After `configure --enable-depend' I try `make' and got gmake[3]: Entering directory `/tmp_mnt/hosts/wisdom/NewSoftware/Ask/build/pgsql/src/backend/port' gcc -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../src/include -c -o ../../utils/strdup.o ../../utils/strdup.c -MMD cp: ../../utils/strdup.d: No such file or directory gmake[3]: *** [../../utils/strdup.o] Error 1 gmake[3]: *** Deleting file `../../utils/strdup.o' gmake[3]: Leaving directory `/tmp_mnt/hosts/wisdom/NewSoftware/Ask/build/pgsql/src/backend/port' The reason is that gcc has bug (or changed feature) in determing there to put .d files: `gcc -MMD x/a.c -c -o x/a.o' puts a.d to the current directory if its version is `2.92.2 19991024', and in x, if its version is `3.1 20010430'. It is looks like the makefile assumes the new behaviour. (Actually, I guess, nobody faced the issue, because developer's systems has `strdup') It is looks like the following patch solves the problem: Index: src/Makefile.global.in =================================================================== RCS file: /home/projects/pgsql/cvsroot/pgsql/src/Makefile.global.in,v retrieving revision 1.123 diff -C2 -r1.123 Makefile.global.in *** src/Makefile.global.in 2001/03/10 10:38:59 1.123 --- src/Makefile.global.in 2001/05/08 10:07:30 *************** *** 367,375 **** # subdirectory, with the dummy targets as explained above. define postprocess-depend ! @if test ! -d $(DEPDIR); then mkdir $(DEPDIR); fi ! @cp $*.d $(df).P ! @sed -e 's/#.*//' -e 's/^[^:]*: *//' -e 's/ *\\$$//' \ ! -e '/^$$/ d' -e 's/$$/ :/' < $*.d >> $(df).P ! @rm -f $*.d endef --- 367,377 ---- # subdirectory, with the dummy targets as explained above. define postprocess-depend ! @if test ! -d $(DEPDIR); then mkdir $(DEPDIR); fi; \ ! if test -f $*.d; then dfile=$*.d ; \ ! else dfile=`basename $*.d` ; fi; \ ! cp $$dfile $(df).P; \ ! sed -e 's/#.*//' -e 's/^[^:]*: *//' -e 's/ *\\$$//' \ ! -e '/^$$/ d' -e 's/$$/ :/' < $$dfile >> $(df).P; \ ! rm -f $$dfile endef BTW: Is there documentation about build process (makefiles structure, etc.)? Another tiny (for quick computer) thing: is it necessary for `make distclean' to call configure, or something is wrong with my environment? And yet another: is it OK for `make depend' to produce gcc -MM -Wall -Wmissing-prototypes -Wmissing-declarations -Wno-error *.c>depend analyze.c:14: postgres.h: No such file or directory analyze.c:16: access/heapam.h: No such file or directory ... Regards, ASK P.S. Search in the mailing lists for `-MMD' failed with Output from Glimpse: glimpse: error in options or arguments to `agrep'
Alexander Klimov writes: > The reason is that gcc has bug (or changed feature) in determing there to > put .d files: `gcc -MMD x/a.c -c -o x/a.o' puts a.d to the current > directory if its version is `2.92.2 19991024', and in x, if its version is > `3.1 20010430'. I have a patch for (better) dependency tracking with gcc >= 3 which will hit CVS soon. Until then, use released compilers or don't use dependency tracking. :-( (The last couple of times I tried gcc >= 3 with PostgreSQL it was a complete disaster anyway, so the former is a good idea in any case ;-).) > BTW: Is there documentation about build process (makefiles structure, > etc.)? Nope. But some should perhaps be written. > Another tiny (for quick computer) thing: is it necessary for `make > distclean' to call configure, or something is wrong with my environment? Hard to tell. Make sure the config.cache isn't messing you up. > And yet another: is it OK for `make depend' to produce make depend doesn't officially exist anymore. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
On Tue, 8 May 2001, Peter Eisentraut wrote: > I have a patch for (better) dependency tracking with gcc >= 3 which will > hit CVS soon. Until then, use released compilers or don't use dependency > tracking. :-( (The last couple of times I tried gcc >= 3 with PostgreSQL > it was a complete disaster anyway, so the former is a good idea in any > case ;-).) The point is that I do use gcc 2.95.2, and it puts .d file in the curent directory, not to the directory there files come from. Anyway, my patch solve the problem at least for me. Regards, ASK
Alexander Klimov writes: > The point is that I do use gcc 2.95.2, and it puts .d file in the curent > directory, not to the directory there files come from. Anyway, my patch > solve the problem at least for me. I see the problem, the port/Makefile needs some changes because it's trying to put output files outside the current directory. Try this patch: diff -c -r1.28 Makefile.in *** Makefile.in 2000/12/11 00:49:54 1.28 --- Makefile.in 2001/05/08 16:42:20 *************** *** 22,29 **** include $(top_builddir)/src/Makefile.global OBJS = dynloader.o @INET_ATON@ @STRERROR@ @MISSING_RANDOM@ @SRANDOM@ ! OBJS+= @GETHOSTNAME@ @GETRUSAGE@ @STRCASECMP@ @STRDUP@ @TAS@ @ISINF@ OBJS+= @STRTOL@ @STRTOUL@ @SNPRINTF@ ifeq ($(PORTNAME),qnx4) OBJS += getrusage.o qnx4/SUBSYS.o endif --- 22,32 ---- include $(top_builddir)/src/Makefile.global OBJS = dynloader.o @INET_ATON@ @STRERROR@ @MISSING_RANDOM@ @SRANDOM@ ! OBJS+= @GETHOSTNAME@ @GETRUSAGE@ @STRCASECMP@ @TAS@ @ISINF@ OBJS+= @STRTOL@ @STRTOUL@ @SNPRINTF@ + ifdef STRDUP + OBJS += $(top_builddir)/src/utils/strdup.o + endif ifeq ($(PORTNAME), qnx4) OBJS += getrusage.o qnx4/SUBSYS.o endif *************** *** 56,61 **** --- 59,68 ---- tas.o: tas.s $(CC) $(CFLAGS) -c $< + + $(top_builddir)/src/utils/strdup.o: + $(MAKE) -C $(top_builddir)/src/utils strdup.o + distclean clean: rm -f SUBSYS.o $(OBJS) ===snip -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter