On Mon, 14 Apr 2008, Lucas Nussbaum wrote: > > Thus closing. > > that's efficient bug triaging :-) > > Which version of dpkg-dev are you using in your build chroot? I suspect > that it is caused by dpkg's last upload. (Ccing Raphael Hertzog)
I can reproduce it too but only when calling directly dpkg-buildpackage and not when calling "debuild". Because debuild has really forked dpkg-buildpackage from what I can see and does not set the same set of variables... gah! The problem is however related to examples/Makefile, quite possibly related to this snippet: ifeq "$(wildcard ../include/factory++.hpp)" "" CPPFLAGS=`pkg-config libfactory++ --cflags` else INCLUDE = .$(shell ln -sf ../include factory++) CPPFLAGS = -I$(INCLUDE) CXXFLAGS += -O0 -g test_factory.o: $(wildcard $(INCLUDE)/factory++/*.hpp) endif If I remove the "-$(MAKE) -C examples clean" call in "debian/rules clean", it works. However trying to call "fakeroot make -C examples clean" doesn't create the bad symlink. I tried adding setting up various environment variables to the values they have during the build done by dpkg-buildpackage but without success. However when I comment out the INCLUDE= line then it works. So it's definitely related to this shell snippet. While stracing the whole process, you'll discover that this shell snippet is executed twice... the first time it creates a "factory++" symlink pointing to ../include and the second time a symlink named include inside ../include pointing to ../include. However the factory++ symlink is removed before the end of the make call since the clean rule does that. If someone has an idea why make calls/parses the makefile twice, I'd be interested. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
