Comments

when setting sysroot to / (for whatever reason), then search directories and
headers start with a double-slash, as seen with gcc -v.
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-linux-gnu/4.6/include
//usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/4.6/include-fixed
//usr/include/x86_64-linux-gnu
//usr/include
End of search list.
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.6/:/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/://lib/x86_64-linux-gnu/://lib/../lib/://usr/lib/x86_64-linux-gnu/://usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../://lib/://usr/lib/
This can end up in generation for dependency files, and other files parsing the
output. The solution I came up with is to check for sysroot set to '/' and
special case this in two places. Afaics, there are no other places.
With the patch, both the include paths and the library paths start with a single
slash. No regressions seen running the testsuite on x86_64-linux-gnu.
Matthias
2012-01-24 Matthias Klose <doko@ubuntu.com>
* gcc.c (add_sysrooted_prefix): Don't prefix with the system root,
if it is the root directory.
* incpath.c (add_standard_paths): Likewise.

On Wed, 25 Jan 2012, Matthias Klose wrote:
> This can end up in generation for dependency files, and other files parsing> the output. The solution I came up with is to check for sysroot set to '/' and> special case this in two places. Afaics, there are no other places.
I could imagine a sysroot path that isn't just '/' but ends with '/'
resulting in duplicate '/' in the middle of the path - although that's not
a correctness issue in the way that '//' at the start could be, maybe the
best check is actually for '/' at end of sysroot (in which case skip the
'/' at the start of the path within the sysroot)? Or remove such a '/' at
end of sysroot at configure time rather than checking for it later....