Bo Ørsted Andresen wrote:
> If you look at the configure script you will see that it's is testing if you
> are on a sparc64. The test shows you aren't which appears to be unrelated to
> your problem. Line 153 which appears to be failing is this:
>
> echo "ARCH=${TARGET_ARCH/i?86/i386}" >> make_include
>
> which is supposed to substitute i686 with i386 in your case and store it in
> make_include as "ARCH=i386". I have no clue why that would fail. The only
> thing that I can think of is to remerge your shell (probably
> app-shells/bash). If noone else has a clue and that doesn't help I guess your
> best option is to file a bug with the info you've posted now...
Thanks for your help, and while it might not have been obvious to you
(or anyone else reading along)... everything that was confusing before
is clear now... to me at least. While I can see what is wrong, it isn't
100% clear if it constitutes a bug or not.
The problem is that the configure script starts '#!/bin/sh' - but goes
on to depend upon Bash specific features... specifically substitution.
I expect this would not be a problem for most users where /bin/sh is a
sym-link to /bin/bash.... but, for me, /bin/sh was a sym-link to
/bin/ash... and, for that shell, line 151 is invalid. What is less
clear is whether or not, in a Gentoo context, it is 'correct' to have
/bin/sh being Borne-like but not Bash-like. By preference I'd prefer
/bin/sh to be the minimal shell that will execute Borne-shell scripts...
but I recognise the Linux-world normality of /bin/sh actually being bash.
As at-least a temporary fix I replaced my /bin/sh->/bin/ash with a
/bin/sh->/bin/bash... and everything now emerges smoothly... From a
prissy perspective I'd have hoped that the configure script would
specify that it needed bash functionality by demanding evaluation by
bash instead of whatever /bin/sh happens to be...
Thanks again,
Steve
--
gentoo-user@gentoo.org mailing list
