I'm trying to cross-compile a PowerPC kernel from an Intel OS X system. 
  I've almost got it working, except "make menuconfig" dies.  It says 
I'm missing ncurses:

  *** Unable to find the ncurses libraries or the
  *** required header files.
  *** 'make menuconfig' requires the ncurses libraries.

However, I do not think that ncurses is the real problem, since I do 
have ncurses installed.  I think the real problem is that the 
check-lxdialog.sh is trying to execute this code:

echo -e ' #include CURSES_LOC \n main() {}' | gcc 
'-DCURSES_LOC=<ncurses.h>' -DLOCALE -DKBUILD_NO_NLS -lncurses -xc - -o 
.lxdialog.tmp

And the compiler is failing with this output:

<stdin>:1: error: syntax error before ‘-’ token
<stdin>:1: error: stray ‘#’ in program

So something strange is going on.  Has anyone been able to cross-compile 
from an Intel Mac running OS X?
--

[ message continues ]

On most linux systems echo supports c-syle escapes with "-e".  I'm
guessing which ever echo you're getting dosesn't do that.

I think the best fix is to ensure you're getting bash as your shell.

A nasty hack would be to make check-lxdialog.sh do something like:
(echo ' #include CURSES_LOC';echo 'main() {}') | gcc '-DCURSES_LOC=<ncurses.h>' -DLOCALE -DKBUILD_NO_NLS -lncurses -xc - -o .lxdialog.tmp

But you'll likley find other palces it breaks.

Yours Tony

  linux.conf.au    http://www.marchsouth.org/
  Jan 19 - 24 2009 The Australian Linux Technical Conference!

--

[ message continues ]

The script starts off with this line:

#!/bin/sh


This works.  Do you think if I posted a patch that makes this change, it will be
accepted?

-- 
Timur Tabi
Linux kernel developer at Freescale
--

[ message continues ]

Yes.

	Sam
--

[ message continues ]

Good grief, folks...

check() {
	$cc -xc - -o $tmp 2>/dev/null <<'EOF'
#include CURSES_LOC
main() {}
EOF
	...
if you insist on feeding these two lines to gcc stdin.  Nasty hack, indeed...

<<'word'
[lines]
word

redirects stdin and feeds lines to it verbatim.  Same without quotes will
do the same, but do expansion in the text first.

It's been there since the original Bourne's shell in v7 and it's a bloody
standard way to redirect from text...
--

[ message continues ]

Thanks Al.
I've queued up the following patch.

	Sam

commit c99cc32e0d92f5fdbdd39a7f42cfff869062fff5
Author: Sam Ravnborg <sam@uranus.ravnborg.org>
Date:   Tue Apr 29 20:02:44 2008 +0200

    kconfig: made check-lxdialog more portable
    
    OS-X shell did not like 'echo -e' so implement
    suggestion from Al Viro to use a more portable construct.
    
    Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
    Cc: Al Viro <viro@ZenIV.linux.org.uk>

diff --git a/scripts/kconfig/lxdialog/check-lxdialog.sh b/scripts/kconfig/lxdialog/check-lxdialog.sh
index 62e1e02..5552154 100644
--- a/scripts/kconfig/lxdialog/check-lxdialog.sh
+++ b/scripts/kconfig/lxdialog/check-lxdialog.sh
@@ -36,8 +36,10 @@ trap "rm -f $tmp" 0 1 2 3 15
 
 # Check if we can link to ncurses
 check() {
-	echo -e " #include CURSES_LOC \n main() {}" |
-	    $cc -xc - -o $tmp 2> /dev/null
+        $cc -xc - -o $tmp 2>/dev/null <<'EOF'
+#include CURSES_LOC
+main() {}
+EOF
 	if [ $? != 0 ]; then
 	    echo " *** Unable to find the ncurses libraries or the"       1>&2
 	    echo " *** required header files."                            1>&2
--

[ message continues ]

Just for the record:

Acked-By: Timur Tabi <timur@freescale.com>

This works on OS X.  I haven't tested it on Linux, though.

FYI, there are other issues that break cross-compiling from OS X, but none of
them are related to /bin/sh.  I'll post patches for those later this week.

-- 
Timur Tabi
Linux kernel developer at Freescale
--

[ message continues ]

Thanks.

	Sam
--

[ message continues ]

This looks O.K.  As a note, whatever behavior is being described here
is system dependent, because on my installation of that other OS, `echo -e'
works fine whether it is invoked as /bin/bash or /bin/sh which appears to be
a strict copy of /bin/bash.

$ uname -v
Darwin Kernel Version 8.11.1: Wed Oct 10 18:23:28 PDT 2007;
root:xnu792.25.20~1/RELEASE_I386

Reviewed-by: SL Baur <steve@xemacs.org>

-sb
--

[ message continues ]

Thanks for your feedback.
The patch is already upstream so I unfortunately 
cannot add your Reviewed-by: tag.

	Sam
--

[ message continues ]

Hi Steve!

Yes, they changed that between Tiger and Leopard, where I have

---
$ uname -v
Darwin Kernel Version 9.2.2: Tue Mar  4 21:17:34 PST 2008;  
root:xnu-1228.4.31~1/RELEASE_I386
$ /bin/bash -c 'echo -e "buh\n"'
buh

$ /bin/sh -c 'echo -e "buh\n"'
-e buh

$ /bin/echo -e "buh\n"
-e buh\n
---

The second one is POSIX+XSI, the third one plain POSIX. The first one  
is what people are used to ;-)

Ciao,
                     Roland

--
Any society that would give up a little liberty to gain a little
security will deserve neither and lose both.  - Benjamin Franklin
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GS/CS/M/MU d-(++) s:+ a-> C+++ UL++++ P+++ L+++ E(+) W+ !N K- w--- M+ ! 
V Y+
PGP++ t+(++) 5 R+ tv-- b+ DI++ e++++ h---- y+++
------END GEEK CODE BLOCK------



[ message continues ]

Check.

$ /bin/bash -c 'echo -e "buh\n"'
buh

$ /bin/sh -c 'echo -e "buh\n"'
buh

$ /bin/echo -e "buh\n"
-e buh\n

Of all the things to "standardize" on, why something like bash
which has no standards?  pdksh, ash, dash or POSIX mode zsh,
would have been better...

-sb
--

[ message continues ]

It also depends on the shell option xpg_echo IIRC.
If xpg_echo is off echo -e should work in /bin/sh, too.

Regards,
Arnd



--

[ message continues ]

Hi Timur!


For some strange reason Apple decided to change 'echo':

/bin/bash -c 'echo -e ...' does the right thing
/bin/sh -c 'echo -e ...' keeps the "-e" in the output but interprets =20
the \n
/bin/echo -e ... does no interpretation and even keeps the \n

I'd recommend installing the coreutils-default package from fink, then =20=

you get a sane /sw/bin/echo.

Side-note on sanity: ISTR that POSIX defines echo in this (/bin/echo) =20=

strange way, urging people to use printf instead.

Ciao,
                     Roland

--
Any society that would give up a little liberty to gain a little
security will deserve neither and lose both.  - Benjamin Franklin
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GS/CS/M/MU d-(++) s:+ a-> C+++ UL++++ P+++ L+++ E(+) W+ !N K- w--- M+ !=20=

V Y+
PGP++ t+(++) 5 R+ tv-- b+ DI++ e++++ h---- y+++
------END GEEK CODE BLOCK------



[ message continues ]

Wow, that is messed up.  Especially since "/bin/sh --version" and "/bin/bash
--version" give me the same output.

Would you say that OS X is broken?  I'm having a hard time finding documentation
for 'sh', so I can't find out what echo -e  is supposed to do in 'sh'.

I read in the latest Linux Journal magazine that someone noticed that even
though the kernel scripts say #!/bin/sh, many of them are really bash scripts.
This person went through the effort of changing the script to be true 'sh'

But the scripts still reference /bin/sh, so I would need to change the scripts
or symlink /bin/sh.  If I'm going to symlink /bin/sh, I'd rather just symlink it

But printf is bash, not sh.  I would need to change #!/bin/sh to #!/bin/bash.

-- 
Timur Tabi
Linux kernel developer at Freescale
--

[ message continues ]

I have no patches pending but I may have lost them.
As I am 100% ignorant about what is bash and what is not bash specialities
I will more or less be blind when I apply them so I hope they are well
tested.

	Sam
--

[ message continues ]

*shrug*

As a sanity check, try to run them with ash(1).  Before going into review
of portability.
--

[ message continues ]

So why use /bin/sh ever in the kernel build system? I consciously  
began using /bin/bash consistently in scripts years ago because you  
just never know what you get when you use /bin/sh. I remember  
replacing /bin/sh with /bin/bash in gcc's build system to get it to  
work on some system at some point. Life is too short to keep having to  
fight silliness like this and I can't see a valid reason why a system  
building a Linux kernel, or for that matter gcc, should not have the  
bash shell installed on it.

And on some systems, changing /bin/sh to point to /bin/bash can result  
in subtle problems with that system's environment, so that is not a  
good option. At least by using /bin/bash you know what you get and the  
dependency is then known to all.

-- 
Mark Rustad, MRustad@gmail.com


--

[ message continues ]

--

[ message continues ]

Hint: not every joe user may install bash into /bin... That's why we
see some scripts begin with "/usr/bin/env bash" as there are less
systems without env in /usr/bin than systems without bash in /bin (or
at all).

Willy

--

[ message continues ]

I agree that #!/bin/bash is a bad idea.  I think the easiest, and maybe the
best, approach is to fix shell issue one-by-one.  The one I found was easily
fixed by Al Viro's here-document change.

-- 
Timur Tabi
Linux kernel developer at Freescale
--

[ message continues ]

/bin/sh standard behaviour is defined.  We follow standards not written or
dictated by us.  I'm proud of that.

-sb
--

[ message continues ]

Too bad #!bash does not search $PATH.
--

[ message continues ]

On Tue, 2008-04-29 at 09:51 -0500, Timur Tabi wrote:

Yes, also:
----  snip  ----
{2}type -all printf
printf is a shell builtin
printf is /usr/bin/printf
----  snip  ----
And the latter is part of coreutils.

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

--

[ message continues ]