FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.

» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian GCC

LinkBack Thread Tools
Old 01-14-2009, 09:33 PM
Stephen McCamant
Default Bug#511854: Include dirs mis-ordered when /usr is a symlink, breaks

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

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:
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:
':trdiff_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:
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

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.


-- Stephen

To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Thread Tools

All times are GMT. The time now is 09:01 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org