https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61918
Bug ID: 61918
Summary: With -isystem, symlinks are sometimes processed
incorrectly
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: mitya57 at gmail dot com
Originally reported at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755767.
Here is the minimal test case:
$ ls -l correct
lrwxrwxrwx 1 dmitry dmitry 16 Jul 26 09:07 first.h -> ../wrong/first.h
-rw-r--r-- 1 dmitry dmitry 0 Jul 26 09:27 second.h
$ ls -l wrong
-rw-r--r-- 1 dmitry dmitry 20 Jul 26 09:07 first.h
-rw-r--r-- 1 dmitry dmitry 38 Jul 26 09:27 second.h
$ cat wrong/first.h
#include "second.h"
$ cat wrong/second.h
#warning Should not include this file
$ cat correct/second.h
$ cat test.c
#include "first.h"
$ cpp -I $(pwd)/correct test.c >/dev/null
$ cpp -isystem $(pwd)/correct test.c >/dev/null
In file included from /tmp/wrong/first.h:1:0,
from test.c:1:
/tmp/wrong/second.h:1:2: warning: #warning Should not include this file [-Wcpp]
#warning Should not include this file
^
$ cpp -isystem ./correct test.c >/dev/null
$
As you can see, correct/first.h is a symlink to wrong/first.h, which in turn
includes second.h. However, I see no reason why cpp follows that symlinks and
opens second.h in wrong directory.
When I use -I instead of -isystem, or use relative file path instead of
absolute, the behavior is correct. Also, clang always handles this correctly.
