On 16-11-2006 19:27:43 +0100, Fabian Groffen wrote:
> > > 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 ?
> >
> > If one adds "-I" with gcc's configured "--prefix"/include, gcc detects
> > this and throws it away with this message:
> >
> > ignoring duplicate directory "<EPREFIX>/usr/include"
> > as it is a non-system directory that duplicates a system directory
>
> I never saw this message on Linux, while we set the flags there too.
> Darwin the same. Is this Solaris specific?
On OSX I we also compile the compilers with ${EPREFIX} iso
${EPREFIX}/usr. The result is as follows:
gcc version 4.0.1 (Apple Computer, Inc. build 5363)
/Library/Gentoo/usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/cc1 -quiet -v
-D__DYNAMIC__ test.c -fPIC -quiet -dumpbase test.c -auxbase test -version -o
/var/tmp//ccr9W1q0.s
ignoring nonexistent directory "/Library/Gentoo/include"
ignoring nonexistent directory
"/Library/Gentoo/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../../powerpc-apple-darwin8/include"
ignoring nonexistent directory "/Library/Gentoo/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
/Library/Gentoo/usr/include
/Library/Gentoo/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/include
/usr/include
/System/Library/Frameworks
/Library/Frameworks
End of search list.
It looks like gcc is smart enough to try "/usr" instead or something. I
saw on other examples of the net people including the "include"
directory as well, which works for them, so I can imagine some fuzzy
stuff is going on there.
Conclusion: it's more correct, but doesn't change the behaviour of our
compilers for now. It seems we can drop the CPPFLAGS from profile.bashrc
--
Fabian Groffen
Gentoo on a different level
--
[EMAIL PROTECTED] mailing list
