Package: g++-4.3 Version: 4.3.2-1.1 It looks like this is the same problem as bug #492817 and maybe also #102473, but those were closed rather than simply being tagged as moreinfo/unreproducible, so my understanding is that a new one is needed.
When /usr is a symlink, g++'s approach for finding what directories should go in the include path works differently; in particular the directories end up in a different order than they would otherwise be in. In version 4.3, the cstddef C++ header file uses #include_next to include stddef.h (which should be in the gcc-lib compiler-specific include directory). The semantics of #include_next mean that it will fail to find the file if the directories are mis-ordered. The problem can be reproduced by making /usr into a symlink on an otherwise vanilla system. I'd be cautious about doing this on a production machine, but it's safe and easy in a chroot. % cat /tmp/test.cpp #include <cstddef> % cd / % ls -ld usr drwxr-xr-x 14 root root 4096 Aug 28 13:58 usr % sudo sh -c 'mv usr real-usr; ln -s real-usr usr' % ls -ld usr real-usr drwxr-xr-x 14 root root 4096 Aug 28 13:58 real-usr lrwxrwxrwx 1 root root 8 Jan 14 14:31 usr -> real-usr % cd /tmp % g++-4.3 -v -c test.cpp -Wall -W ... #include <...> search starts here: /real-usr/bin/../lib/gcc/i486-linux-gnu/4.3.2/include /real-usr/bin/../lib/gcc/i486-linux-gnu/4.3.2/include-fixed /real-usr/bin/../lib/gcc/../../include/c++/4.3 /real-usr/bin/../lib/gcc/../../include/c++/4.3/i486-linux-gnu /real-usr/bin/../lib/gcc/../../include/c++/4.3/backward /usr/local/include /usr/include/i486-linux-gnu /usr/include End of search list. ... In file included from test.cpp:1: /real-usr/bin/../lib/gcc/../../include/c++/4.3/cstddef:48:25: error: stddef.h: No such file or directory In file included from test.cpp:1: /real-usr/bin/../lib/gcc/../../include/c++/4.3/cstddef:55: error: '::ptrdiff_t' has not been declared % cd / % sudo sh -c 'rm usr; mv real-usr usr' % cd /tmp % g++-4.3 -v -c test.cpp -Wall -W ... #include <...> search starts here: /usr/include/c++/4.3 /usr/include/c++/4.3/i486-linux-gnu /usr/include/c++/4.3/backward /usr/local/include /usr/lib/gcc/i486-linux-gnu/4.3.2/include /usr/lib/gcc/i486-linux-gnu/4.3.2/include-fixed /usr/include/i486-linux-gnu /usr/include End of search list. ... [compiles without errors] The transcript above is from a Lenny chroot, but I've also encountered the bug on an Ubuntu 8.10 laptop where I had used a /usr symlink to work around a too-small root partition. As a workaround, it appears that using a bind mount instead of a symlink avoids tickling this problem. This and a related failure mode are tracked as GCC bugs #36505 and #38000 upstream. It appears that the GCC developers have decided that this use of #include_next was a mistake, so for 4.3.3 and 4.4.0 this will be fixed by reverting to a regular #include. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36505 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38000 -- Stephen -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
