On 16-11-2006 21:20:35 +0100, Michael Haubenwallner wrote:
> On Thu, 2006-11-16 at 19:27 +0100, Fabian Groffen wrote:
> > <snip>
> > > > 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?
> > >
> > > Did not consider $PREFIX versus /usr yet, but "${EPREFIX}/usr" is
> > > correct for --with-local-prefix, because if $PREFIX changes to somewhat
> > > like /usr/gcc, gcc won't search $EPREFIX/usr/include any more, but only
> > > $EPREFIX/usr/gcc/include.
> >
> > PREFIX=${TOOLCHAIN_PREFIX:-/usr}
> >
> > so I replaced your /usr by ${PREFIX} as I think it's correct. If you
> > mess with the variable, you should know what you're doing.
>
> Erm, $PREFIX is the toolchain-prefix, not the local-prefix.
> The toolchain-prefix ( ${EPREFIX}${PREFIX} ) is searched by gcc
> independently of local-prefix ( ${EPREFIX}/usr ).
> When toolchain-prefix changes (where can $TOOLCHAIN_PREFIX come from ?),
> there's no reason to change local-prefix automagically too.
> If one decides to change toolchain-prefix, why should she have an idea
> to consider local-prefix too ?
Hmmm... I have the impression TOOLCHAIN_PREFIX is used for cross-setups,
where you want the compiler to read from ${PREFIX}/include instead,
because you also have glibc and system headers installed there. Does
that make sense at all?
> > > 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?
>
> You only see this message in verbose mode (-v) as the output of "cc1":
> $ gcc -v -c -I $EPREFIX/usr/include file.c
See the follow-up message I wrote. I don't see the exact message, but
similar messages.
> I just tried it on Linux with gcc-4.1.1 from my toolsbox, built with
> similar setup.
On my Linux compiler it doesn't, but I've rebuilt it with the right
local-prefix now.
> > > So the CPPFLAGS setting was useless even without any of these patches,
> > > this is why I said "non-working workaround".
> >
> > I included them, because otherwise openssh wouldn't compile, because it
> > didn't find an up-to-date enough openssl header...
>
> Strange - are you sure you used gcc emerged with that setup ?
No. And since it works fine everywhere I tried now with the portage
built compilers, I removed the CPPFLAGS hack, as I think there's too
much hackery in the profile.bashrc files anyway.
> BTW, do you have amd64-cpu for your x86-solaris ?
> My 'emerge system' just bailed out at openssl, because it tries to build
> 64bit here, which doesn't work yet with GNU as. Patch coming soon.
Nope, some AMD Athlon thing, so can't help you there.
Thanks.
--
Fabian Groffen
Gentoo on a different level
--
[EMAIL PROTECTED] mailing list
