Hi Michael,
Thanks for figuring this out! In general, I think double slashes are
ugly, so getting rid of them is always a Good Thing(tm). The first two
patches do this, and hence serve a double purpose to me: fixing and
beautification.
The last patch I think is right too. I'm waiting for my compiler to be
built now. Question is whether it shouldn't use ${EPREFIX}${PREFIX}
instead of ${EPREFIX}/usr. Did you do this intentionally?
Last question, which relates to the subject of this mail; does the last
patch in priniciple fix the compiler search path to have the prefix
includes first, like now is attempted to be achieved with the CPPFLAGS?
I.o.w. is CPPFLAGS (as we use) unnecessary for compilers built with a
correct --with-local-prefix ?
On 15-11-2006 21:41:14 +0100, Michael Haubenwallner wrote:
> Hi,
>
> while emerging nano after the "--enable-overwrite" change for ncurses, I
> had another very strange problem:
>
> Even if "curses.h" was available in EPREFIX/usr/include, gcc
> used /usr/include/curses.h (the system-one, without eprefix).
>
> Playing with "gcc -v", I saw that the fixed system headers were always
> included _before_ the EPREFIX/usr/include, even if "-I
> EPREFIX/usr/include" was on the commandline (through CPPFLAGS from
> profile.bashrc).
>
> As a result, I filed a gcc bug for that:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29831
>
> But after reading bug-summary, provided that EPREFIX is not a symlink
> (mine was :-( ), you'd say: Hey, our gcc is neither moved nor symlinked!
>
> Well, that's true, but gcc "thinks" it is moved, because we ./configure
> it with "--bindir=/the/eprefix//usr/i386-sun-solaris2.10/gcc-bin/4.1.1".
>
> The problem is the double slash in "eprefix//usr", which triggers that
> bug. What happens here is: gcc uses the path of its argv[0] to detect
> whether it is moved or not. And if the builtin "--bindir" is different
> than physical dirname(argv[0]), gcc calculates relative pathnames for
> its own include- and lib-dirs, passing an "-iprefix" argument to "cc1",
> which causes "cc1" to change the include path order.
>
> Try it, and look at the include-path warnings from "cc1" - it's
> unbeleavable!
>
> Anyway, attached [toolchain-doubleslash.patch] avoids triggering this
> bug if EPREFIX does not contain symlinks.
>
> Found similar double slashes in toolchain-binutils.eclass.
> Though I have not encountered a problem, I'd rather have them removed
> [toolchain-binutils.patch]
>
> Btw, [toolchain-local-prefix] passes correct local prefix to
> "--with-local-prefix", as $EPREFIX is the wrong one (we don't have
> $EPREFIX/include, and $EPREFIX/lib is special).
>
> /haubi/
--
Fabian Groffen
Gentoo on a different level
--
[EMAIL PROTECTED] mailing list
