Bug#511854: Include dirs mis-ordered when /usr is a symlink, breaks <cstddef>
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
Reply to: