cross-compiling on OS X, make menuconfig fails

cross-compiling on OS X, make menuconfig fails

[timur]

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?

Re: cross-compiling on OS X, make menuconfig fails

[Tony Breeds]

On Sun, Apr 27, 2008 at 08:34:46PM -0500, timur@freescale.com wrote:
> I'm trying to cross-compile a PowerPC kernel from an Intel OS X system. 

<snip>
 
> 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

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!

Re: cross-compiling on OS X, make menuconfig fails

[Roland Kuhn]

[-- Attachment #1: Type: text/plain, Size: 1875 bytes --]

Hi Timur!

On 28 Apr 2008, at 03:34, timur@freescale.com wrote:

> 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?

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  
the \n
/bin/echo -e ... does no interpretation and even keeps the \n

I'd recommend installing the coreutils-default package from fink, then  
you get a sane /sw/bin/echo.

Side-note on sanity: ISTR that POSIX defines echo in this (/bin/echo)  
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+ ! 
V Y+
PGP++ t+(++) 5 R+ tv-- b+ DI++ e++++ h---- y+++
------END GEEK CODE BLOCK------




[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

Re: cross-compiling on OS X, make menuconfig fails

[Timur Tabi]

Roland Kuhn wrote:

> 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  
> the \n
> /bin/echo -e ... does no interpretation and even keeps the \n

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'
scripts.  Has that code been merged in?

> I'd recommend installing the coreutils-default package from fink, then  
> you get a sane /sw/bin/echo.

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
to /bin/bash.

> Side-note on sanity: ISTR that POSIX defines echo in this (/bin/echo)  
> strange way, urging people to use printf instead.

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

-- 
Timur Tabi
Linux kernel developer at Freescale

Re: cross-compiling on OS X, make menuconfig fails

[Timur Tabi]

Tony Breeds wrote:

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

Yes, that is my problem.

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

The script starts off with this line:

#!/bin/sh

Doesn't that mean that it should be interpreted by sh and not bash?

> 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

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

Re: cross-compiling on OS X, make menuconfig fails

[Sam Ravnborg]

> 
> 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'
> scripts.  Has that code been merged in?

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

Re: cross-compiling on OS X, make menuconfig fails

[Sam Ravnborg]

On Tue, Apr 29, 2008 at 10:07:43AM -0500, Timur Tabi wrote:
> Tony Breeds wrote:
> 
> > On most linux systems echo supports c-syle escapes with "-e".  I'm
> > guessing which ever echo you're getting dosesn't do that.
> 
> Yes, that is my problem.
> 
> > I think the best fix is to ensure you're getting bash as your shell.
> 
> The script starts off with this line:
> 
> #!/bin/sh
> 
> Doesn't that mean that it should be interpreted by sh and not bash?
> 
> > 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
> 
> This works.  Do you think if I posted a patch that makes this change, it will be
> accepted?

Yes.

	Sam

Re: cross-compiling on OS X, make menuconfig fails

[Al Viro]

On Tue, Apr 29, 2008 at 06:45:01PM +0200, Sam Ravnborg wrote:
> > 
> > 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'
> > scripts.  Has that code been merged in?
> 
> 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.

*shrug*

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

Re: cross-compiling on OS X, make menuconfig fails

[Al Viro]

On Tue, Apr 29, 2008 at 06:45:35PM +0200, Sam Ravnborg wrote:
> On Tue, Apr 29, 2008 at 10:07:43AM -0500, Timur Tabi wrote:
> > Tony Breeds wrote:
> > 
> > > On most linux systems echo supports c-syle escapes with "-e".  I'm
> > > guessing which ever echo you're getting dosesn't do that.
> > 
> > Yes, that is my problem.
> > 
> > > I think the best fix is to ensure you're getting bash as your shell.
> > 
> > The script starts off with this line:
> > 
> > #!/bin/sh
> > 
> > Doesn't that mean that it should be interpreted by sh and not bash?
> > 
> > > 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
> > 
> > This works.  Do you think if I posted a patch that makes this change, it will be
> > accepted?
> 
> Yes.

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...

Re: cross-compiling on OS X, make menuconfig fails

[Sam Ravnborg]

> 
> Good grief, folks...

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

Re: Why use /bin/sh in kernel build system?

[Mark Rustad]

On Apr 29, 2008, at 11:45 AM, Sam Ravnborg wrote:

>> 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'
>> scripts.  Has that code been merged in?
>
> 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.


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

Re: Why use /bin/sh in kernel build system?

[Alexey Dobriyan]

On Tue, Apr 29, 2008 at 03:27:02PM -0500, Mark Rustad wrote:
> On Apr 29, 2008, at 11:45 AM, Sam Ravnborg wrote:
>
>>> 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'
>>> scripts.  Has that code been merged in?
>>
>> 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.
>
>
> 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.

Think harder.

> 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.

Re: Why use /bin/sh in kernel build system?

[Willy Tarreau]

On Wed, Apr 30, 2008 at 01:41:07AM +0400, Alexey Dobriyan wrote:
> On Tue, Apr 29, 2008 at 03:27:02PM -0500, Mark Rustad wrote:
> > On Apr 29, 2008, at 11:45 AM, Sam Ravnborg wrote:
> >
> >>> 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'
> >>> scripts.  Has that code been merged in?
> >>
> >> 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.
> >
> >
> > 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.
> 
> Think harder.

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

Re: Why use /bin/sh in kernel build system?

[Timur Tabi]

Willy Tarreau wrote:

> 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).

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

Re: cross-compiling on OS X, make menuconfig fails

[Bernd Petrovitsch]

On Tue, 2008-04-29 at 09:51 -0500, Timur Tabi wrote:
[...]
> But printf is bash, not sh.  I would need to change #!/bin/sh to #!/bin/bash.

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

Re: Why use /bin/sh in kernel build system?

[SL Baur]

On 4/29/08, Willy Tarreau <w@1wt.eu> wrote:
>  > On Tue, Apr 29, 2008 at 03:27:02PM -0500, Mark Rustad wrote:

>  > > 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.

> 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).

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

-sb

Re: Why use /bin/sh in kernel build system?

[Jan Engelhardt]

On Wednesday 2008-04-30 00:24, Willy Tarreau wrote:
>
>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).

Too bad #!bash does not search $PATH.

Re: cross-compiling on OS X, make menuconfig fails

[Timur Tabi]

Sam Ravnborg wrote:
>> Good grief, folks...
> 
> 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>

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

Re: cross-compiling on OS X, make menuconfig fails

[Sam Ravnborg]

On Wed, Apr 30, 2008 at 08:54:54AM -0500, Timur Tabi wrote:
> Sam Ravnborg wrote:
> >> Good grief, folks...
> > 
> > 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>
> 
> 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.
Thanks.

	Sam

Re: cross-compiling on OS X, make menuconfig fails

[SL Baur]

On 4/29/08, Sam Ravnborg <sam@ravnborg.org> wrote:
> >
>  > Good grief, folks...
>
>  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

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

Re: cross-compiling on OS X, make menuconfig fails

[Sam Ravnborg]

> 
> 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>

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

	Sam

Re: cross-compiling on OS X, make menuconfig fails

[Roland Kuhn]

[-- Attachment #1: Type: text/plain, Size: 2539 bytes --]

Hi Steve!

On 3 May 2008, at 08:55, SL Baur wrote:

> On 4/29/08, Sam Ravnborg <sam@ravnborg.org> wrote:
>>>
>>> Good grief, folks...
>>
>> 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
>
> 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
>
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------




[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

Re: cross-compiling on OS X, make menuconfig fails

[SL Baur]

On 5/3/08, Roland Kuhn <rkuhn@e18.physik.tu-muenchen.de> wrote:
> Hi Steve!
>
>
>  On 3 May 2008, at 08:55, SL Baur wrote:

> > $ uname -v
> > Darwin Kernel Version 8.11.1: Wed Oct 10 18:23:28 PDT 2007;
> > root:xnu792.25.20~1/RELEASE_I386
> >
> >
>  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 ;-)

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

Re: cross-compiling on OS X, make menuconfig fails

[Arnd Hannemann]

SL Baur wrote:
> On 5/3/08, Roland Kuhn <rkuhn@e18.physik.tu-muenchen.de> wrote:
>   
>> Hi Steve!
>>
>>
>>  On 3 May 2008, at 08:55, SL Baur wrote:
>>     
>
>   
>>> $ uname -v
>>> Darwin Kernel Version 8.11.1: Wed Oct 10 18:23:28 PDT 2007;
>>> root:xnu792.25.20~1/RELEASE_I386
>>>
>>>
>>>       
>>  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 ;-)
>>     
>
> 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...
>
>   
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