Bug 29831 - changed include order when symlinking prefix or moving binaries
Summary: changed include order when symlinking prefix or moving binaries
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: preprocessor (show other bugs)
Version: 4.1.1
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-11-14 14:05 UTC by Michael Haubenwallner
Modified: 2009-03-29 23:43 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2009-03-29 23:43:01


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Haubenwallner 2006-11-14 14:05:35 UTC
Have built gcc with "--prefix=/usr/local/gcc-4.1.1".

When "/usr/local/gcc-4.1.1" is moved and symlinked to "/stranger/gcc-4.1.1", the include path order changes, so that fixed system headers are searched before local headers.

In non-symlink case, where the searched include path is correct, I can see this output (with focus on the include path):

$ /usr/local/gcc-4.1.1/bin/gcc -c -v xx.c
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /ftp/pub/source/gcc/gcc-4.1.1.orig/configure --prefix=/usr/local/gcc-4.1.1 --enable-languages=c
Thread model: posix
gcc version 4.1.1
 /usr/local/gcc-4.1.1/libexec/gcc/i686-pc-linux-gnu/4.1.1/cc1 -quiet -v xx.c -quiet -dumpbase xx.c -mtune=pentiumpro -auxbase xx -version -o /tmp/ccL8OzjB.s
ignoring nonexistent directory "/usr/local/gcc-4.1.1/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/local/gcc-4.1.1/include
 /usr/local/gcc-4.1.1/lib/gcc/i686-pc-linux-gnu/4.1.1/include
 /usr/include
End of search list.
GNU C version 4.1.1 (i686-pc-linux-gnu)
        compiled by GNU C version 4.1.1 (Gentoo 4.1.1).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 36febb42c74478a1ecbe6b4467b0f6b8
 as -V -Qy -o xx.o /tmp/ccL8OzjB.s
GNU assembler version 2.16.1 (i686-pc-linux-gnu) using BFD version 2.16.1


When I move and symlink /usr/local/gcc-4.1.1 to /stranger/gcc-4.1.1, the include order changes:

$ mkdir /stranger
$ mv /usr/local/gcc-4.1.1 /stranger
$ ln -s /stranger/gcc-4.1.1 /usr/local
$ /usr/local/gcc-4.1.1/bin/gcc -c -v xx.c
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /ftp/pub/source/gcc/gcc-4.1.1.orig/configure --prefix=/usr/local/gcc-4.1.1 --enable-languages=c
Thread model: posix
gcc version 4.1.1
 /stranger/gcc-4.1.1/bin/../libexec/gcc/i686-pc-linux-gnu/4.1.1/cc1 -quiet -v -iprefix /stranger/gcc-4.1.1/bin/../lib/gcc/i686-pc-linux-gnu/4.1.1/ xx.c -quiet -dumpbase xx.c -mtune=pentiumpro -auxbase xx -version -o /tmp/cc0hiBMc.s
ignoring nonexistent directory "/stranger/gcc-4.1.1/bin/../lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../i686-pc-linux-gnu/include"
ignoring duplicate directory "/usr/local/gcc-4.1.1/lib/gcc/i686-pc-linux-gnu/4.1.1/include"
ignoring nonexistent directory "/usr/local/gcc-4.1.1/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /stranger/gcc-4.1.1/bin/../lib/gcc/i686-pc-linux-gnu/4.1.1/include
 /usr/local/include
 /usr/local/gcc-4.1.1/include
 /usr/include
End of search list.
GNU C version 4.1.1 (i686-pc-linux-gnu)
        compiled by GNU C version 4.1.1 (Gentoo 4.1.1).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 36febb42c74478a1ecbe6b4467b0f6b8
 as -V -Qy -o xx.o /tmp/cc0hiBMc.s
GNU assembler version 2.16.1 (i686-pc-linux-gnu) using BFD version 2.16.1


The basic difference is that "cc1" gets called as:
  "/stranger/gcc-4.1.1/bin/../libexec/gcc/i686-pc-linux-gnu/4.1.1/cc1"
with this additional argument:
  "-iprefix /stranger/gcc-4.1.1/bin/../lib/gcc/i686-pc-linux-gnu/4.1.1/"


Additionally, when _moving_ to /stranger/gcc-4.1.1, "/stranger/gcc-4.1.1/include" does not get searched any more, while fixed system headers continue being searched first:

$ rm /usr/local/gcc-4.1.1
$ /stranger/gcc-4.1.1/bin/gcc -c -v xx.c
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /ftp/pub/source/gcc/gcc-4.1.1.orig/configure --prefix=/usr/local/gcc-4.1.1 --enable-languages=c
Thread model: posix
gcc version 4.1.1
 /stranger/gcc-4.1.1/bin/../libexec/gcc/i686-pc-linux-gnu/4.1.1/cc1 -quiet -v -iprefix /stranger/gcc-4.1.1/bin/../lib/gcc/i686-pc-linux-gnu/4.1.1/ xx.c -quiet -dumpbase xx.c -mtune=pentiumpro -auxbase xx -version -o /tmp/ccIr1Gz5.s
ignoring nonexistent directory "/stranger/gcc-4.1.1/bin/../lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../i686-pc-linux-gnu/include"
ignoring nonexistent directory "/usr/local/gcc-4.1.1/include"
ignoring nonexistent directory "/usr/local/gcc-4.1.1/lib/gcc/i686-pc-linux-gnu/4.1.1/include"
ignoring nonexistent directory "/usr/local/gcc-4.1.1/i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /stranger/gcc-4.1.1/bin/../lib/gcc/i686-pc-linux-gnu/4.1.1/include
 /usr/local/include
 /usr/include
End of search list.
GNU C version 4.1.1 (i686-pc-linux-gnu)
        compiled by GNU C version 4.1.1 (Gentoo 4.1.1).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 36febb42c74478a1ecbe6b4467b0f6b8
 as -V -Qy -o xx.o /tmp/ccIr1Gz5.s
GNU assembler version 2.16.1 (i686-pc-linux-gnu) using BFD version 2.16.1


This is not only on linux, but on most (all?) unices too.
Comment 1 Michael Haubenwallner 2006-11-15 21:08:33 UTC
And it does happen when configured with pathes containing double slashes,
fex .../configure --prefix=/my/prefix//usr --bindir=/my/prefix//usr/bin