[PATCH] ct-ng build debug shell

[PATCH] ct-ng build debug shell

[Johannes Stezenbach]

Add experimental debug config option to make crosstool-NG
drop into shell prompt on build errors instead of
just aborting the build.

Signed-off-by: Johannes Stezenbach <js@sig21.net>

diff -r c94bf1e11db2 config/global/ct-behave.in
--- a/config/global/ct-behave.in	Mon Oct 15 11:48:02 2012 +0200
+++ b/config/global/ct-behave.in	Mon Oct 15 17:24:08 2012 +0200
@@ -71,6 +71,25 @@
       further doesn't gain much, and takes far more time (believe me, I've
       got figures here! :-) ).
 
+config DEBUG_CT_FIXUP_SHELL
+    bool
+    prompt "Drop into shell prompt on build errors"
+    depends on EXPERIMENTAL
+    help
+      By default. crosstool-NG terminates the build when a build
+      command fails.  When this option is selected, crosstool-NG
+      instead drops into a shell prompt, with the environment set
+      up appropriately to re-run build commands manually to debug
+      the failure or even hot-fix it.  You then have three choices,
+      which you select by the shell exit code:
+        exit 1: you hot-fixed the issue, continue with the next build command
+        exit 2: ask crosstool-NG to re-run the failed build command
+        exit 3: ask crosstool-NG to abort the build
+      Other exit codes and ^D just cause crosstool-NG to restart the
+      shell and print a helpful message.
+      Note that this feature is disabled if stdin, stdout or stderr
+      are not to a terminal.
+
 config NO_OVERIDE_LC_MESSAGES
     bool
     prompt "Do *not* overide LC_MESSAGES (EXPERIMENTAL)"
diff -r c94bf1e11db2 scripts/crosstool-NG.sh.in
--- a/scripts/crosstool-NG.sh.in	Mon Oct 15 11:48:02 2012 +0200
+++ b/scripts/crosstool-NG.sh.in	Mon Oct 15 17:24:08 2012 +0200
@@ -25,6 +25,15 @@
 . .config.2
 # Yes! We can do full logging from now on!
 
+if [ "${CT_DEBUG_CT_FIXUP_SHELL}" = "y" ]; then
+	# Note: stdout is saved in fd 6
+	if [ -t 0 -a -t 6 -a -t 2 ]; then
+		CT_DoExecLog() { CT_DoExecLog_WithFixupShell "$@"; }
+	else
+		CT_DoLog WARN "CT_DEBUG_CT_FIXUP_SHELL disabled due to I/O redirection"
+	fi
+fi
+
 # Override the locale early, in case we ever translate crosstool-NG messages
 if [ -z "${CT_NO_OVERIDE_LC_MESSAGES}" ]; then
     export LC_ALL=C
diff -r c94bf1e11db2 scripts/functions
--- a/scripts/functions	Mon Oct 15 11:48:02 2012 +0200
+++ b/scripts/functions	Mon Oct 15 17:24:08 2012 +0200
@@ -175,6 +175,61 @@
     [ $? -eq 0 ]
 }
 
+# Variant of CT_DoExecLog for CT_DEBUG_CT_FIXUP_SHELL=y
+CT_DoExecLog_WithFixupShell() {
+    local level="$1"
+    local result
+    shift
+    (
+    for i in "$@"; do
+        tmp_log+="'${i}' "
+    done
+    while true; do
+        case "${1}" in
+            *=*)    eval export "'${1}'"; shift;;
+            *)      break;;
+        esac
+    done
+    trap ERR
+    while true; do
+        CT_DoLog DEBUG "==> Executing: ${tmp_log}"
+        "${@}" 2>&1 |CT_DoLog "${level}"
+        result=$?
+        if [ $result -eq 0 ]; then
+            break
+        fi
+        (
+            exec >&6
+            echo "command error $result:"
+            echo "$@"
+            echo "please fix it up and finish by exiting the shell"
+            while true; do
+                bash --rcfile <(echo "PS1='ct-ng:\w> '") -i
+                result=$?
+                case $result in
+                    1)  result=0; break;;
+                    2)  break;;
+                    3)  break;;
+                    *)  echo "please exit with one of these values:"
+                        echo "1  fixed, continue with next build command"
+                        echo "2  repeat this build command"
+                        echo "3  abort build"
+                        ;;
+                esac
+            done
+            exit $result
+        )
+        result=$?
+        if [ $result -ne 2 ]; then
+            break
+        fi
+    done
+    exit $result
+    )
+    # Catch failure of the sub-shell
+    [ $? -eq 0 ]
+}
+
 # Tail message to be logged whatever happens
 # Usage: CT_DoEnd <level>
 CT_DoEnd()

--
For unsubscribe information see http://sourceware.org/lists.html#faq

[PATCH 1 of 1] scripts: add option to start an interactive debug shell

[Yann E. MORIN]

# HG changeset patch
# User "Yann E. MORIN" <yann.morin.1998@free.fr>
# Date 1349560087 -7200
# Node ID 82c19a72f25a7b399f6be4e2c8c1cecc45d8c171
# Parent  2a616dab6531ad82876c3252cd2e1cb873375c3f
scripts: add option to start an interactive debug shell

Add an option that, when a command fails:
  - starts an interactive shell with the failed command's environment
  - attempts re-execution of the failed command, continue, or aborts
    at user's whim.

Based on an idea and a patch from: Johannes Stezenbach <js@sig21.net>
    http://sourceware.org/ml/crossgcc/2012-09/msg00144.html

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Johannes Stezenbach <js@sig21.net>

diff --git a/config/global/ct-behave.in b/config/global/ct-behave.in
--- a/config/global/ct-behave.in
+++ b/config/global/ct-behave.in
@@ -87,4 +87,22 @@
       
       Say N, please.
 
+config DEBUG_INTERACTIVE
+    bool
+    prompt "Interactive shell on failed commands"
+    depends on EXPERIMENTAL
+    help
+      If you say 'y' here, then an interactive shell will be spawned for
+      each failed command run via CT_DoExecLog.
+      
+      This shell will have the same environment that the failed command
+      was run with, and the working directory will be set to the directory
+      the failed command was run in.
+      
+      After you fix the issue, you can exit the interactive shell with any
+      of these exit codes:
+        1  the issue was fixed, continue the build with the next command
+        2  the issue was fixed, re-run the failed command
+        3  abort the build
+
 endif
diff --git a/scripts/functions b/scripts/functions
--- a/scripts/functions
+++ b/scripts/functions
@@ -5,10 +5,45 @@
 # Prepare the fault handler
 CT_OnError() {
     local ret=$?
+    local old_trap result
     local intro
     local file line func
     local step step_depth
 
+    # If the user asked for interactive debugging, dump him/her to a shell
+    if [ "${CT_DEBUG_INTERACTIVE}" = "y" ]; then
+        # We do not want this sub-shell exit status to be caught
+        old_trap="$(trap -p ERR)"
+        trap ERR
+        (
+            exec >&6
+            printf "Current command\n  %s\n" "${cur_cmd}"
+            printf "exited with error code: %d\n" ${ret}
+            printf "Please fix it up and finish by exiting the shell.\n"
+            while true; do
+                bash --rcfile <(echo "PS1='ct-ng:\w> '") -i
+                result=$?
+                case $result in
+                    1)  break;;
+                    2)  break;;
+                    3)  break;;
+                    *)  echo "please exit with one of these values:"
+                        echo "1  fixed, continue with next build command"
+                        echo "2  repeat this build command"
+                        echo "3  abort build"
+                        ;;
+                esac
+            done
+            exit $result
+        )
+        result=$?
+        case "${result}" in
+            1)  return;;
+            2)  touch "${CT_BUILD_DIR}/repeat"; return;;
+            # 3 is an abort, continue...
+        esac
+    fi
+
     # To avoid printing the backtace for each sub-shell
     # up to the top-level, just remember we've dumped it
     if [ ! -f "${CT_BUILD_DIR}/backtrace" ]; then
@@ -157,10 +192,11 @@
 # Usage: CT_DoExecLog <level> [VAR=val...] <command> [parameters...]
 CT_DoExecLog() {
     local level="$1"
+    local cur_cmd
     shift
     (
     for i in "$@"; do
-        tmp_log+="'${i}' "
+        cur_cmd+="'${i}' "
     done
     while true; do
         case "${1}" in
@@ -168,8 +204,39 @@
             *)      break;;
         esac
     done
-    CT_DoLog DEBUG "==> Executing: ${tmp_log}"
-    "${@}" 2>&1 |CT_DoLog "${level}"
+    # This while-loop goes hand-in-hand with the ERR trap handler:
+    # - if the command terminates successfully, then we hit the break
+    #   statement, and we exit the loop
+    # - if the command terminates in error, then the ERR handler kicks
+    #   in, then:
+    #     - if the user did *not* ask for interactive debugging, the ERR
+    #       handler exits, and we hit the end of the sub-shell
+    #     - if the user did ask for interactive debugging, the ERR handler
+    #       spawns a shell. Upon termination of this shell, the ERR handler
+    #       examines the exit status of the shell:
+    #         - if 1, the ERR handler returns; then we hit the else statement,
+    #           then the break, and we exit the 'while' loop, to continue the
+    #           build;
+    #         - if 2, the ERR handler touches the repeat file, and returns;
+    #           then we hit the if statement, and we loop for one more
+    #           iteration;
+    #         - if 3, the ERR handler exits with the command's exit status,
+    #           and we're dead;
+    #         - for any other exit status of the shell, the ERR handler
+    #           prints an informational message, and respawns the shell
+    #
+    # This allows a user to get an interactive shell that has the same
+    # environment (PATH and so on) that the failed command was ran with.
+    while true; do
+        rm -f "${CT_BUILD_DIR}/repeat"
+        CT_DoLog DEBUG "==> Executing: ${cur_cmd}"
+        "${@}" 2>&1 |CT_DoLog "${level}"
+        if [ -f "${CT_BUILD_DIR}/repeat" ]; then
+            continue
+        else
+            break
+        fi
+    done
     )
     # Catch failure of the sub-shell
     [ $? -eq 0 ]

--
For unsubscribe information see http://sourceware.org/lists.html#faq

[PATCH 0 of 1] Alternative debug-shell implementation

[Yann E. MORIN]

Johannes, All,

Here is an alternate implementation of debug-shell, that I was working on
following your previous submission.

I prefer it over yours (even the revised one), becasue:
  - it does not duplicate CT_DoExecLog
  - it is integrated in the fault handler
  - it messes up with the trap, but in the fault handler, not
    in the normal code path
  
It's still not finished ( needs eg.: s/bash/${bash}/ ), and I did not yet
fully tested it, but it seems all is fitted in place.

I was working on it, since you said "I'm out of time atm and can't finish it."
Of course, your initial submission was of great help to come up with this
alternate solution! Thank you! :-)

Regards,
Yann E. MORIN.

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: [PATCH 1 of 1] scripts: add option to start an interactive debug shell

[Yann E. MORIN]

Johannes, All,

[Replying on my own patch. Yikes! ;-) ]

On Monday 15 October 2012 Yann E. MORIN wrote:
> # HG changeset patch
> # User "Yann E. MORIN" <yann.morin.1998@free.fr>
> # Date 1349560087 -7200
> # Node ID 82c19a72f25a7b399f6be4e2c8c1cecc45d8c171
> # Parent  2a616dab6531ad82876c3252cd2e1cb873375c3f
> scripts: add option to start an interactive debug shell
[--SNIP--]
> diff --git a/scripts/functions b/scripts/functions
> --- a/scripts/functions
> +++ b/scripts/functions
> @@ -5,10 +5,45 @@
>  # Prepare the fault handler
>  CT_OnError() {
>      local ret=$?
> +    local old_trap result
>      local intro
>      local file line func
>      local step step_depth
>  
> +    # If the user asked for interactive debugging, dump him/her to a shell
> +    if [ "${CT_DEBUG_INTERACTIVE}" = "y" ]; then

The debug-shell should not be spawned for commands that were not run via
CT_DoExecLog, otherwise it is impossible to properly resume, although it
would be possible to just 'continue' or 'abort', not 'repeat'.

So, what do you think for non-CT_DoExecLog commands:
  - don't run debug-shell at all, or
  - run debug-shell, but only allow 'continue' or 'abort' ?

Note: use [ -n "${cur_cmd}" ] to check if we're in CT_DoExecLog.

> +        # We do not want this sub-shell exit status to be caught
> +        old_trap="$(trap -p ERR)"

No need to save the old trap, it's not used.
Or, what was I thinking in the first place to do that?... O_o

> @@ -157,10 +192,11 @@
>  # Usage: CT_DoExecLog <level> [VAR=val...] <command> [parameters...]
>  CT_DoExecLog() {
>      local level="$1"
> +    local cur_cmd
>      shift
>      (
>      for i in "$@"; do
> -        tmp_log+="'${i}' "
> +        cur_cmd+="'${i}' "
>      done
>      while true; do
>          case "${1}" in

The hunk above could well be a separate cset.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

--
For unsubscribe information see http://sourceware.org/lists.html#faq

[PATCH 0 of 1] Alternate debug-shell implementation, v2

[Yann E. MORIN]

Johannes, All,

Here is the final implementation.

As you did the initial work, I kept your SoB-line.
Tell me if you want me to remove it.

Regards,
Yann E. MORIN.

--
For unsubscribe information see http://sourceware.org/lists.html#faq

[PATCH 1 of 1] scripts: add option to start an interactive debug shell

[Yann E. MORIN]

# HG changeset patch
# User "Yann E. MORIN" <yann.morin.1998@free.fr>
# Date 1349560087 -7200
# Node ID de0568d968da614fe8f7287dbd4d65e51b6096e2
# Parent  2a616dab6531ad82876c3252cd2e1cb873375c3f
scripts: add option to start an interactive debug shell

Add an option that, when a command fails:
  - starts an interactive shell with the failed command's environment
  - attempts re-execution of the failed command, continues, or aborts
    at user's whim.

Before starting the debug-shell, the backtrace is printed.
When exiting for an abort, the standard error message is printed.

Based on an idea and a patch from: Johannes Stezenbach <js@sig21.net>
    http://sourceware.org/ml/crossgcc/2012-09/msg00144.html

Signed-off-by: Johannes Stezenbach <js@sig21.net>
[yann.morin.1998@free.fr: integrate in the fault handler]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Patchwork-Id: 191571
Patchwork-Id: 191657

diff --git a/config/global/ct-behave.in b/config/global/ct-behave.in
--- a/config/global/ct-behave.in
+++ b/config/global/ct-behave.in
@@ -87,4 +87,23 @@
       
       Say N, please.
 
+config DEBUG_INTERACTIVE
+    bool
+    prompt "Interactive shell on failed commands"
+    help
+      If you say 'y' here, then an interactive shell will be spawned for
+      each failed command.
+      
+      This shell will have the same environment that the failed command
+      was run with, and the working directory will be set to the directory
+      the failed command was run in.
+      
+      After you fix the issue, you can exit the interactive shell with any
+      of these exit codes:
+        1  the issue was fixed, continue the build with the next command
+        2  the issue was fixed, re-run the failed command
+        3  abort the build
+      
+      Note: '2' is only possible for commands run via CT_DoExecLog, though.
+
 endif
diff --git a/scripts/functions b/scripts/functions
--- a/scripts/functions
+++ b/scripts/functions
@@ -5,6 +5,8 @@
 # Prepare the fault handler
 CT_OnError() {
     local ret=$?
+    local result
+    local old_trap
     local intro
     local file line func
     local step step_depth
@@ -35,6 +37,62 @@
             CT_DoLog ERROR ">>  ${intro}: ${func}[${file}${line}]"
             intro="      called from"
         done
+
+        # If the user asked for interactive debugging, dump him/her to a shell
+        if [ "${CT_DEBUG_INTERACTIVE}" = "y" ]; then
+            # We do not want this sub-shell exit status to be caught, because
+            # it is absolutely legit that it exits with non-zero.
+            # Save the trap handler to restore it after our debug-shell
+            old_trap="$(trap -p ERR)"
+            trap -- ERR
+            (
+                exec >&6
+                printf "\r         \n\nCurrent command"
+                if [ -n "${cur_cmd}" ]; then
+                    printf ":\n  %s\n" "${cur_cmd}"
+                else
+                    printf " (unknown), "
+                fi
+                printf "exited with error code: %d\n" ${ret}
+                printf "Please fix it up and finish by exiting the shell with one of these values:\n"
+                printf "    1  fixed, continue with next build command\n"
+                if [ -n "${cur_cmd}" ]; then
+                    printf "    2  repeat this build command\n"
+                fi
+                printf "    3  abort build\n\n"
+                while true; do
+                    ${bash} --rcfile <(printf "PS1='ct-ng:\w> '\nPROMPT_COMMAND=''\n") -i
+                    result=$?
+                    case $result in
+                        1)  printf "\nContinuing past the failed command.\n\n"
+                            break
+                            ;;
+                        2)  if [ -n "${cur_cmd}" ]; then
+                                printf "\nRe-trying last command.\n\n"
+                                break
+                            fi
+                            ;;&
+                        3)  break;;
+                        *)  printf "\nPlease exit with one of these values:\n"
+                            printf "    1  fixed, continue with next build command\n"
+                            if [ -n "${cur_cmd}" ]; then
+                                printf "    2  repeat this build command\n"
+                            fi
+                            printf "    3  abort build\n"
+                            ;;
+                    esac
+                done
+                exit $result
+            )
+            result=$?
+            # Restore the trap handler
+            eval "${old_trap}"
+            case "${result}" in
+                1)  rm -f "${CT_BUILD_DIR}/backtrace"; return;;
+                2)  rm -f "${CT_BUILD_DIR}/backtrace"; touch "${CT_BUILD_DIR}/repeat"; return;;
+                # 3 is an abort, continue...
+            esac
+        fi
     fi
 
     # And finally, in top-level shell, print some hints
@@ -157,10 +215,11 @@
 # Usage: CT_DoExecLog <level> [VAR=val...] <command> [parameters...]
 CT_DoExecLog() {
     local level="$1"
+    local cur_cmd
     shift
     (
     for i in "$@"; do
-        tmp_log+="'${i}' "
+        cur_cmd+="'${i}' "
     done
     while true; do
         case "${1}" in
@@ -168,8 +227,39 @@
             *)      break;;
         esac
     done
-    CT_DoLog DEBUG "==> Executing: ${tmp_log}"
-    "${@}" 2>&1 |CT_DoLog "${level}"
+    # This while-loop goes hand-in-hand with the ERR trap handler:
+    # - if the command terminates successfully, then we hit the break
+    #   statement, and we exit the loop
+    # - if the command terminates in error, then the ERR handler kicks
+    #   in, then:
+    #     - if the user did *not* ask for interactive debugging, the ERR
+    #       handler exits, and we hit the end of the sub-shell
+    #     - if the user did ask for interactive debugging, the ERR handler
+    #       spawns a shell. Upon termination of this shell, the ERR handler
+    #       examines the exit status of the shell:
+    #         - if 1, the ERR handler returns; then we hit the else statement,
+    #           then the break, and we exit the 'while' loop, to continue the
+    #           build;
+    #         - if 2, the ERR handler touches the repeat file, and returns;
+    #           then we hit the if statement, and we loop for one more
+    #           iteration;
+    #         - if 3, the ERR handler exits with the command's exit status,
+    #           and we're dead;
+    #         - for any other exit status of the shell, the ERR handler
+    #           prints an informational message, and respawns the shell
+    #
+    # This allows a user to get an interactive shell that has the same
+    # environment (PATH and so on) that the failed command was ran with.
+    while true; do
+        rm -f "${CT_BUILD_DIR}/repeat"
+        CT_DoLog DEBUG "==> Executing: ${cur_cmd}"
+        "${@}" 2>&1 |CT_DoLog "${level}"
+        if [ -f "${CT_BUILD_DIR}/repeat" ]; then
+            continue
+        else
+            break
+        fi
+    done
     )
     # Catch failure of the sub-shell
     [ $? -eq 0 ]

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: [PATCH 0 of 1] Alternative debug-shell implementation

[Johannes Stezenbach]

Hi Yann,

On Mon, Oct 15, 2012 at 09:53:55PM +0200, Yann E. MORIN wrote:
> Here is an alternate implementation of debug-shell, that I was working on
> following your previous submission.
> 
> I prefer it over yours (even the revised one), becasue:
>   - it does not duplicate CT_DoExecLog
>   - it is integrated in the fault handler
>   - it messes up with the trap, but in the fault handler, not
>     in the normal code path
>   
> It's still not finished ( needs eg.: s/bash/${bash}/ ), and I did not yet
> fully tested it, but it seems all is fitted in place.
> 
> I was working on it, since you said "I'm out of time atm and can't finish it."
> Of course, your initial submission was of great help to come up with this
> alternate solution! Thank you! :-)

That's fine, I had a small amount of spare time yesterday and
brushed up my patches since it looked like noone else would do it.
But I like you version actually better than mine.
I'll test it soo but I can't make any promises as to when I get around...

Thanks
Johannes

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: [PATCH 0 of 1] Alternative debug-shell implementation

[Yann E. MORIN]

Johannes, All,

On Tuesday 16 October 2012 Johannes Stezenbach wrote:
> On Mon, Oct 15, 2012 at 09:53:55PM +0200, Yann E. MORIN wrote:
> > Here is an alternate implementation of debug-shell, that I was working on
> > following your previous submission.
[--SNIP--]
> > I was working on it, since you said "I'm out of time atm and can't finish it."
> > Of course, your initial submission was of great help to come up with this
> > alternate solution! Thank you! :-)
> 
> That's fine, I had a small amount of spare time yesterday and
> brushed up my patches since it looked like noone else would do it.
> But I like you version actually better than mine.
> I'll test it soo but I can't make any promises as to when I get around...

OK, I'll wait a bit for your ACK, then. Thank you! :-)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: [PATCH 0 of 1] Alternative debug-shell implementation

[Johannes Stezenbach]

Hi Yann,

On Tue, Oct 16, 2012 at 08:53:29PM +0200, Yann E. MORIN wrote:
> On Tuesday 16 October 2012 Johannes Stezenbach wrote:
> > On Mon, Oct 15, 2012 at 09:53:55PM +0200, Yann E. MORIN wrote:
> > > Here is an alternate implementation of debug-shell, that I was working on
> > > following your previous submission.
> [--SNIP--]
> > > I was working on it, since you said "I'm out of time atm and can't finish it."
> > > Of course, your initial submission was of great help to come up with this
> > > alternate solution! Thank you! :-)
> > 
> > That's fine, I had a small amount of spare time yesterday and
> > brushed up my patches since it looked like noone else would do it.
> > But I like you version actually better than mine.
> > I'll test it soo but I can't make any promises as to when I get around...
> 
> OK, I'll wait a bit for your ACK, then. Thank you! :-)

My patch had this test:

+       if [ -t 0 -a -t 6 -a -t 2 ]; then
+              ...
+       else
+               CT_DoLog WARN "CT_DEBUG_CT_FIXUP_SHELL disabled due to I/O redirection"
+       fi

I haven't tested what happens if you run "c-ng build |& tee log" and
then try to run an interactive shell, but I guess it can't work?

Then, I'm running in this:

[INFO ]  Checking C library configuration
[ERROR]    You did not provide an eglibc config file!
[ERROR]
[ERROR]  >>
[ERROR]  >>  Build failed in step '(top-level)'
[ERROR]  >>
[ERROR]  >>  Error happened in: main[scripts/crosstool-NG.sh@585]


Current command (unknown), exited with error code: 1
Please fix it up and finish by exiting the shell with one of these values:
    1  fixed, continue with next build command
    3  abort build

ct-ng:~/tmp/tc/build>

Where scripts/crosstool-NG.sh@585 is "for step in ${CT_STEPS}; do".
I guess we can live with that but since there is no command
to fix or re-run it is a bit odd.


Best Regards
Johannes

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: [PATCH 0 of 1] Alternative debug-shell implementation

[Johannes Stezenbach]

Hi,

and another mino issue:  when it runs into an error it prints:

Current command:
  'make' '-j5' 'all'
exited with error code: 2


It would be more useful to print a command that could be copy&pasted.


Best Regards
Johannes

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: [PATCH 0 of 1] Alternative debug-shell implementation

[Yann E. MORIN]

Johannes, All,

On Wednesday 17 October 2012 13:13:06 Johannes Stezenbach wrote:
> and another mino issue:  when it runs into an error it prints:
> 
> Current command:
>   'make' '-j5' 'all'
> exited with error code: 2
> 
> 
> It would be more useful to print a command that could be copy&pasted.

Well, that *can* be copy-pasted. Especially if there are arguments with
spaces, then they are properly quoted.

For example, try this at your prompt:
    $ 'printf' '==%s==\n' 'arg1' 'arg 2'
    ==arg1==
    ==arg 2==

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |   ^                |
| --==< O_o >==-- '------------.-------:  X  AGAINST      |  /e\  There is no  |
| http://ymorin.is-a-geek.org/ | (*_*) | / \ HTML MAIL    |  """  conspiracy.  |
'------------------------------'-------'------------------'--------------------'

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: [PATCH 0 of 1] Alternative debug-shell implementation

[Yann E. MORIN]

Johannes, All,

On Wednesday 17 October 2012 12:15:21 Johannes Stezenbach wrote:
> > > On Mon, Oct 15, 2012 at 09:53:55PM +0200, Yann E. MORIN wrote:
> > > > Here is an alternate implementation of debug-shell, that I was working on
> > > > following your previous submission.

> My patch had this test:
> 
> +       if [ -t 0 -a -t 6 -a -t 2 ]; then
> +              ...
> +       else
> +               CT_DoLog WARN "CT_DEBUG_CT_FIXUP_SHELL disabled due to I/O redirection"
> +       fi
> 
> I haven't tested what happens if you run "c-ng build |& tee log" and
> then try to run an interactive shell, but I guess it can't work?

Right, I'll see what I can do to add ths check.

> Then, I'm running in this:
> 
> [INFO ]  Checking C library configuration
> [ERROR]    You did not provide an eglibc config file!
> [ERROR]
> [ERROR]  >>
> [ERROR]  >>  Build failed in step '(top-level)'
> [ERROR]  >>
> [ERROR]  >>  Error happened in: main[scripts/crosstool-NG.sh@585]
> 
> 
> Current command (unknown), exited with error code: 1
> Please fix it up and finish by exiting the shell with one of these values:
>     1  fixed, continue with next build command
>     3  abort build
> 
> ct-ng:~/tmp/tc/build>
> 
> Where scripts/crosstool-NG.sh@585 is "for step in ${CT_STEPS}; do".
> I guess we can live with that but since there is no command
> to fix or re-run it is a bit odd.

That's the question: for commands that are not run via CT_DoExecLog, do we
want to spawn the debug-shell anyway, even if we can't display the command
that failed? My opinion is: yes, because we ant to debug the fscking b!tch,
even it it means a bit of rummaging...

At least, with the location in the error message and/or the last INFO line
of the log, it should be relatively  easy to find the real location of the
original error.

And remember that the debug-shell is just that: a debug-shell. Stumbling
across such a case can be fixed by adding a CT_DoExecLog in front of the
offending command.

In this specific case, I don't see what's wrong after just a quick glance,
but I think it's better to fix CT_TestOrAbort (and the likes) to properly
fail. I'll look at it tonight, when back home.

Thanks for the review!

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |   ^                |
| --==< O_o >==-- '------------.-------:  X  AGAINST      |  /e\  There is no  |
| http://ymorin.is-a-geek.org/ | (*_*) | / \ HTML MAIL    |  """  conspiracy.  |
'------------------------------'-------'------------------'--------------------'

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: [PATCH 0 of 1] Alternative debug-shell implementation

[Johannes Stezenbach]

Hi Yann,

On Wed, Oct 17, 2012 at 01:38:38PM +0200, Yann E. MORIN wrote:
> On Wednesday 17 October 2012 12:15:21 Johannes Stezenbach wrote:
> > 
> > Current command (unknown), exited with error code: 1
> > Please fix it up and finish by exiting the shell with one of these values:
> >     1  fixed, continue with next build command
> >     3  abort build
> > 
> > ct-ng:~/tmp/tc/build>
> > 
> > Where scripts/crosstool-NG.sh@585 is "for step in ${CT_STEPS}; do".
> > I guess we can live with that but since there is no command
> > to fix or re-run it is a bit odd.
> 
> That's the question: for commands that are not run via CT_DoExecLog, do we
> want to spawn the debug-shell anyway, even if we can't display the command
> that failed? My opinion is: yes, because we ant to debug the fscking b!tch,
> even it it means a bit of rummaging...
> 
> At least, with the location in the error message and/or the last INFO line
> of the log, it should be relatively  easy to find the real location of the
> original error.
> 
> And remember that the debug-shell is just that: a debug-shell. Stumbling
> across such a case can be fixed by adding a CT_DoExecLog in front of the
> offending command.
> 
> In this specific case, I don't see what's wrong after just a quick glance,
> but I think it's better to fix CT_TestOrAbort (and the likes) to properly
> fail. I'll look at it tonight, when back home.

OK, guess it was just a bit unexpected for me, but it's OK.
You've got my ACK on the patch.

Thank you,
Johannes

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: [PATCH 0 of 1] Alternative debug-shell implementation

[Johannes Stezenbach]

Hi Yann,

On Wed, Oct 17, 2012 at 01:38:38PM +0200, Yann E. MORIN wrote:
> On Wednesday 17 October 2012 12:15:21 Johannes Stezenbach wrote:
> > > > On Mon, Oct 15, 2012 at 09:53:55PM +0200, Yann E. MORIN wrote:
> > > > > Here is an alternate implementation of debug-shell, that I was working on
> > > > > following your previous submission.
> 
> > My patch had this test:
> > 
> > +       if [ -t 0 -a -t 6 -a -t 2 ]; then
> > +              ...
> > +       else
> > +               CT_DoLog WARN "CT_DEBUG_CT_FIXUP_SHELL disabled due to I/O redirection"
> > +       fi
> > 
> > I haven't tested what happens if you run "c-ng build |& tee log" and
> > then try to run an interactive shell, but I guess it can't work?
> 
> Right, I'll see what I can do to add ths check.

I just ran into an endless loop with today's ct-ng, which was caused
by a patch failing to apply in CT_Patch.  The problem is that
the failed command uses stdin redirection.

  [INFO ]  Extracting and patching toolchain components
  [EXTRA]    Extracting 'eglibc-2_16'
  [EXTRA]    Patching 'eglibc-2_16'
  [ERROR]
  [ERROR]  >>
  [ERROR]  >>  Build failed in step 'Extracting and patching toolchain components'
  [ERROR]  >>        called in step '(top-level)'
  [ERROR]  >>
  [ERROR]  >>  Error happened in: CT_DoExecLog[scripts/functions@257]
  [ERROR]  >>        called from: CT_Patch[scripts/functions@1054]
  [ERROR]  >>        called from: do_libc_extract[scripts/build/libc/glibc-eglibc.sh-common@10]
  [ERROR]  >>        called from: main[scripts/crosstool-NG.sh@580]
  
  
  Current command:
    'patch' '--no-backup-if-mismatch' '-g0' '-F1' '-p1' '-f'
  exited with error code: 1
  Please fix it up and finish by exiting the shell with one of these values:
      1  fixed, continue with next build command
      2  repeat this build command
      3  abort build
  
  ct-ng:~/toolchain/eglibc/build/.build/src/eglibc-2_16> exit
  
  Please exit with one of these values:
  (... repeat ...)


The easiest fix for this particular case would be to use "patch -i patch"
instead of "patch <patch" (-i is in POSIX), which would also have the
advantage that the patch filename would show up in the failed command.
But in general I guess the fix might be:


--- functions.orig	2012-10-26 14:04:35.767316717 +0200
+++ functions	2012-10-26 14:19:06.921870258 +0200
@@ -46,7 +46,7 @@ CT_OnError() {
             old_trap="$(trap -p ERR)"
             trap -- ERR
             (
-                exec >&6
+                exec >&6 2>&7 <&8
                 printf "\r         \n\nCurrent command"
                 if [ -n "${cur_cmd}" ]; then
                     printf ":\n  %s\n" "${cur_cmd}"
@@ -131,7 +131,7 @@ set +o hashall
 
 # Log policy:
 #  - first of all, save stdout so we can see the live logs: fd #6
-exec 6>&1
+exec 6>&1 7>&2 8<&0
 #  - then point stdout to the log file
 tmp_log_file="${CT_TOP_DIR}/build.log"
 rm -f "${tmp_log_file}"


Another issue is that "1  fixed, continue with next build command"
doesn't seem to work since the exit status isn't cleared
and CT_DoExecLog() fails again.  Maybe we need something like
"${CT_BUILD_DIR}/repeat" for the "continue" case?


Thanks
Johannes

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: [PATCH 0 of 1] Alternative debug-shell implementation

[Yann E. MORIN]

Johannes, All,

On Friday 26 October 2012 Johannes Stezenbach wrote:
> > > > > On Mon, Oct 15, 2012 at 09:53:55PM +0200, Yann E. MORIN wrote:
> > > > > > Here is an alternate implementation of debug-shell, that I was working on
> > > > > > following your previous submission.
[--SNIP--]
> I just ran into an endless loop with today's ct-ng, which was caused
> by a patch failing to apply in CT_Patch.  The problem is that
> the failed command uses stdin redirection.

Ah, good catch.

[--SNIP--]
> The easiest fix for this particular case would be to use "patch -i patch"
> instead of "patch <patch" (-i is in POSIX), which would also have the
> advantage that the patch filename would show up in the failed command.

Yep, let's use "patch -i".
I was not happy with the redirection anyway.

> But in general I guess the fix might be:
> 
> 
> --- functions.orig	2012-10-26 14:04:35.767316717 +0200
> +++ functions	2012-10-26 14:19:06.921870258 +0200
> @@ -46,7 +46,7 @@ CT_OnError() {
>              old_trap="$(trap -p ERR)"
>              trap -- ERR
>              (
> -                exec >&6
> +                exec >&6 2>&7 <&8
>                  printf "\r         \n\nCurrent command"
>                  if [ -n "${cur_cmd}" ]; then
>                      printf ":\n  %s\n" "${cur_cmd}"
> @@ -131,7 +131,7 @@ set +o hashall
>  
>  # Log policy:
>  #  - first of all, save stdout so we can see the live logs: fd #6
> -exec 6>&1
> +exec 6>&1 7>&2 8<&0
>  #  - then point stdout to the log file
>  tmp_log_file="${CT_TOP_DIR}/build.log"
>  rm -f "${tmp_log_file}"

Care to send a proper patch with your SoB line, please?

> Another issue is that "1  fixed, continue with next build command"
> doesn't seem to work since the exit status isn't cleared
> and CT_DoExecLog() fails again.  Maybe we need something like
> "${CT_BUILD_DIR}/repeat" for the "continue" case?

I'll double check, but I remember it to work for me...
I even added this code to test retry/resume/abort:
    CT_DoExecLog DEBUG false false-01
    CT_DoExecLog DEBUG false false-02
    CT_DoExecLog DEBUG false false-03

And I was able to either retry/resume/abort.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

--
For unsubscribe information see http://sourceware.org/lists.html#faq

[PATCH] fix endless loop in debug-shell with IO redirection

[Johannes Stezenbach]

CT_DEBUG_INTERACTIVE is disabled when stdin, stdout or
stderr are redirected, but the check is only done at
the start of the build and doesn't catch when individual
build commands use redirection.  When stdin is redirected
it will cause the debug shell to exit immediately, causing
and endless loop.  Thus, save the stdin/our/err file handles
and restore them before invoking the debug shell.

Signed-off-by: Johannes Stezenbach <js@sig21.net>

diff -r 9f6e46b6dc42 scripts/functions
--- a/scripts/functions	Tue Oct 30 00:23:51 2012 +0100
+++ b/scripts/functions	Tue Oct 30 11:13:17 2012 +0100
@@ -46,7 +46,7 @@
             old_trap="$(trap -p ERR)"
             trap -- ERR
             (
-                exec >&6
+                exec >&6 2>&7 <&8
                 printf "\r         \n\nCurrent command"
                 if [ -n "${cur_cmd}" ]; then
                     printf ":\n  %s\n" "${cur_cmd}"
@@ -131,7 +131,8 @@
 
 # Log policy:
 #  - first of all, save stdout so we can see the live logs: fd #6
-exec 6>&1
+# (also save stdin and stderr for use by CT_DEBUG_INTERACTIVE)
+exec 6>&1 7>&2 8<&0
 #  - then point stdout to the log file
 tmp_log_file="${CT_TOP_DIR}/build.log"
 rm -f "${tmp_log_file}"

--
For unsubscribe information see http://sourceware.org/lists.html#faq

[PATCH] use patch -i instead of IO redirection

[Johannes Stezenbach]

The makes the patch name show up on the command line
logged by CT_DoExecLog so it's easier to see
what is going on.  The -i for patch is specified
by Posix and supported by GNU patch and busybox patch.

Signed-off-by: Johannes Stezenbach <js@sig21.net>

diff -r 9f6e46b6dc42 scripts/functions
--- a/scripts/functions	Tue Oct 30 00:23:51 2012 +0100
+++ b/scripts/functions	Tue Oct 30 11:24:46 2012 +0100
@@ -1051,7 +1051,7 @@
             for p in "${d}"/*.patch; do
                 if [ -f "${p}" ]; then
                     CT_DoLog DEBUG "Applying patch '${p}'"
-                    CT_DoExecLog ALL patch --no-backup-if-mismatch -g0 -F1 -p1 -f <"${p}"
+                    CT_DoExecLog ALL patch --no-backup-if-mismatch -g0 -F1 -p1 -f -i "${p}"
                 fi
             done
             if [ "${CT_PATCH_SINGLE}" = "y" ]; then

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: [PATCH 0 of 1] Alternative debug-shell implementation

[Johannes Stezenbach]

Hi Yann,

On Fri, Oct 26, 2012 at 07:43:37PM +0200, Yann E. MORIN wrote:
> On Friday 26 October 2012 Johannes Stezenbach wrote:
> > Another issue is that "1  fixed, continue with next build command"
> > doesn't seem to work since the exit status isn't cleared
> > and CT_DoExecLog() fails again.  Maybe we need something like
> > "${CT_BUILD_DIR}/repeat" for the "continue" case?
> 
> I'll double check, but I remember it to work for me...
> I even added this code to test retry/resume/abort:
>     CT_DoExecLog DEBUG false false-01
>     CT_DoExecLog DEBUG false false-02
>     CT_DoExecLog DEBUG false false-03
> 
> And I was able to either retry/resume/abort.

It doesn't seem to work as intended, but I've had no time to
debug it yet.  Here's output from one build failure where
I tried to continue with "exit 1".  As you can see, the build
stopped a few more times where I also used "exit 1".  At one
point I decided to give up with "exit 3" which caused a few
strange errors and then the build continued to the end!?

Maybe you can make sense of it.

Here are the two errors from the longer log below:

  scripts/functions: line 401: stop-: syntax error: operand expected (error token is "-")

    399 CT_EndStep() {
    400     local stop=$(CT_DoDate +%s%N)
    401     local duration=$(printf "%032d" $((stop-${CT_STEP_START[${CT_STEP_COUNT}]})) |sed -r -e 's/([[:digit:]]{2})[[:digit:]]{7}$/\.\1/; s/^0+//; s/^\./0\./;')

  scripts/functions: line 199: [: -le: unary operator expected
    168 CT_DoLog() {
    ...
    199               if [ ${cur_l} -le ${max_level} ]; then

Even though it's not fully working yet the debug shell is
still very useful for me.  Saved me a lot of time. :-)


Thanks
Johannes


(note the build was running on some ancient RedHat machine
so the actual build error is not so interesting for you)

[INFO ]  Installing C library
[EXTRA]    Configuring C library
[EXTRA]    Building C library
[EXTRA]    Installing C library
[EXTRA]    Building and installing the C library manual
[ERROR]    make[3]: *** [/tmp/toolchain-eglibc-201210/bld/.build/arm-unknown-linux-gnueabi/build/build-libc-final/manual/libc.pdf]
 Error 1
[ERROR]    make[2]: *** [pdf] Error 2
[ERROR]    make[1]: *** [pdf] Error 2
[ERROR]
[ERROR]  >>
[ERROR]  >>  Build failed in step 'Installing C library'
[ERROR]  >>        called in step '(top-level)'
[ERROR]  >>
[ERROR]  >>  Error happened in: CT_DoExecLog[scripts/functions@257]
[ERROR]  >>        called from: do_libc_backend_once[scripts/build/libc/glibc-eglibc.sh-common@455]
[ERROR]  >>        called from: do_libc_backend[scripts/build/libc/glibc-eglibc.sh-common@143]
[ERROR]  >>        called from: do_libc[scripts/build/libc/glibc-eglibc.sh-common@65]
[ERROR]  >>        called from: main[scripts/crosstool-NG.sh@609]


Current command:
  'make' 'pdf' 'html'
exited with error code: 2
Please fix it up and finish by exiting the shell with one of these values:
    1  fixed, continue with next build command
    2  repeat this build command
    3  abort build

ct-ng:/tmp/toolchain-eglibc-201210/bld/.build/arm-unknown-linux-gnueabi/build/build-libc-final> 'make' 'pdf' 'html'
... (snipped)
ct-ng:/tmp/toolchain-eglibc-201210/bld/.build/arm-unknown-linux-gnueabi/build/build-libc-final> exit 1
exit

Continuing past the failed command.

[ERROR]
[ERROR]  >>
[ERROR]  >>  Build failed in step 'Installing C library'
[ERROR]  >>        called in step '(top-level)'
[ERROR]  >>
[ERROR]  >>  Error happened in: CT_DoExecLog[scripts/functions@216]
[ERROR]  >>        called from: do_libc_backend_once[scripts/build/libc/glibc-eglibc.sh-common@455]
[ERROR]  >>        called from: do_libc_backend[scripts/build/libc/glibc-eglibc.sh-common@143]
[ERROR]  >>        called from: do_libc[scripts/build/libc/glibc-eglibc.sh-common@65]
[ERROR]  >>        called from: main[scripts/crosstool-NG.sh@609]
         /

Current command (unknown), exited with error code: 2
Please fix it up and finish by exiting the shell with one of these values:
    1  fixed, continue with next build command
    3  abort build

ct-ng:/tmp/toolchain-eglibc-201210/bld/.build/arm-unknown-linux-gnueabi/build/build-libc-final> exit 1
exit

Continuing past the failed command.

[ERROR]
[ERROR]  >>
[ERROR]  >>  Build failed in step '(top-level)'
[ERROR]  >>
[ERROR]  >>  Error happened in: CT_DoExecLog[scripts/functions@268]
[ERROR]  >>        called from: do_libc_backend_once[scripts/build/libc/glibc-eglibc.sh-common@455]
[ERROR]  >>        called from: do_libc_backend[scripts/build/libc/glibc-eglibc.sh-common@143]
[ERROR]  >>        called from: do_libc[scripts/build/libc/glibc-eglibc.sh-common@65]
[ERROR]  >>        called from: main[scripts/crosstool-NG.sh@609]
         /

Current command (unknown), exited with error code: 1
Please fix it up and finish by exiting the shell with one of these values:
    1  fixed, continue with next build command
    3  abort build

ct-ng:/tmp/toolchain-eglibc-201210/bld/.build/arm-unknown-linux-gnueabi/build/build-libc-final> exit 1
exit

Continuing past the failed command.

[ERROR]
[ERROR]  >>
[ERROR]  >>  Build failed in step '(top-level)'
[ERROR]  >>
[ERROR]  >>  Error happened in: do_libc_backend_once[scripts/build/libc/glibc-eglibc.sh-common@91]
[ERROR]  >>        called from: do_libc_backend[scripts/build/libc/glibc-eglibc.sh-common@143]
[ERROR]  >>        called from: do_libc[scripts/build/libc/glibc-eglibc.sh-common@65]
[ERROR]  >>        called from: main[scripts/crosstool-NG.sh@609]
         /

Current command (unknown), exited with error code: 1
Please fix it up and finish by exiting the shell with one of these values:
    1  fixed, continue with next build command
    3  abort build

ct-ng:/tmp/toolchain-eglibc-201210/bld/.build/arm-unknown-linux-gnueabi/build/build-libc-final> exit 1
exit

Continuing past the failed command.

[EXTRA]  Configuring C library localedef
[EXTRA]  Building C library localedef
[ERROR]  glibc/locale/programs/../../intl/l10nflist.c:328: error: 'locale_t' undeclared (first use in this function)
[ERROR]  glibc/locale/programs/../../intl/l10nflist.c:328: error: (Each undeclared identifier is reported only once
[ERROR]  glibc/locale/programs/../../intl/l10nflist.c:328: error: for each function it appears in.)
[ERROR]  glibc/locale/programs/../../intl/l10nflist.c:328: error: expected ';' before 'locale'
[ERROR]  make[1]: *** [locarchive.o] Error 1
[ERROR]  |
[ERROR]  >>
[ERROR]  >>  Build failed in step '(top-level)'
[ERROR]  >>
[ERROR]  >>  Error happened in: CT_DoExecLog[scripts/functions@257]
[ERROR]  >>        called from: do_libc_locales[scripts/build/libc/eglibc.sh@153]
[ERROR]  >>        called from: do_libc_backend_once[scripts/build/libc/glibc-eglibc.sh-common@469]
[ERROR]  >>        called from: do_libc_backend[scripts/build/libc/glibc-eglibc.sh-common@143]
[ERROR]  >>        called from: do_libc[scripts/build/libc/glibc-eglibc.sh-common@65]
[ERROR]  >>        called from: main[scripts/crosstool-NG.sh@609]
         /

Current command:
  'make' '-j3'
exited with error code: 2
Please fix it up and finish by exiting the shell with one of these values:
    1  fixed, continue with next build command
    2  repeat this build command
    3  abort build

ct-ng:/tmp/toolchain-eglibc-201210/bld/.build/arm-unknown-linux-gnueabi/build/build-localedef> make
... (snipped)
ct-ng:/tmp/toolchain-eglibc-201210/bld/.build/arm-unknown-linux-gnueabi/build/build-localedef> exit 1
exit

Continuing past the failed command.

[ERROR]
[ERROR]  >>
[ERROR]  >>  Build failed in step '(top-level)'
[ERROR]  >>
[ERROR]  >>  Error happened in: CT_DoExecLog[scripts/functions@216]
[ERROR]  >>        called from: do_libc_locales[scripts/build/libc/eglibc.sh@153]
[ERROR]  >>        called from: do_libc_backend_once[scripts/build/libc/glibc-eglibc.sh-common@469]
[ERROR]  >>        called from: do_libc_backend[scripts/build/libc/glibc-eglibc.sh-common@143]
[ERROR]  >>        called from: do_libc[scripts/build/libc/glibc-eglibc.sh-common@65]
[ERROR]  >>        called from: main[scripts/crosstool-NG.sh@609]
         /

Current command (unknown), exited with error code: 2
Please fix it up and finish by exiting the shell with one of these values:
    1  fixed, continue with next build command
    3  abort build

ct-ng:/tmp/toolchain-eglibc-201210/bld/.build/arm-unknown-linux-gnueabi/build/build-localedef> exit 1
exit

Continuing past the failed command.

[ERROR]
[ERROR]  >>
[ERROR]  >>  Build failed in step '(top-level)'
[ERROR]  >>
[ERROR]  >>  Error happened in: CT_DoExecLog[scripts/functions@268]
[ERROR]  >>        called from: do_libc_locales[scripts/build/libc/eglibc.sh@153]
[ERROR]  >>        called from: do_libc_backend_once[scripts/build/libc/glibc-eglibc.sh-common@469]
[ERROR]  >>        called from: do_libc_backend[scripts/build/libc/glibc-eglibc.sh-common@143]
[ERROR]  >>        called from: do_libc[scripts/build/libc/glibc-eglibc.sh-common@65]
[ERROR]  >>        called from: main[scripts/crosstool-NG.sh@609]
         /

Current command (unknown), exited with error code: 1
Please fix it up and finish by exiting the shell with one of these values:
    1  fixed, continue with next build command
    3  abort build

ct-ng:/tmp/toolchain-eglibc-201210/bld/.build/arm-unknown-linux-gnueabi/build/build-localedef> exit 1
exit

Continuing past the failed command.

[ERROR]
[ERROR]  >>
[ERROR]  >>  Build failed in step '(top-level)'
[ERROR]  >>
[ERROR]  >>  Error happened in: do_libc_locales[scripts/build/libc/eglibc.sh@91]
[ERROR]  >>        called from: do_libc_backend_once[scripts/build/libc/glibc-eglibc.sh-common@469]
[ERROR]  >>        called from: do_libc_backend[scripts/build/libc/glibc-eglibc.sh-common@143]
[ERROR]  >>        called from: do_libc[scripts/build/libc/glibc-eglibc.sh-common@65]
[ERROR]  >>        called from: main[scripts/crosstool-NG.sh@609]
         /

Current command (unknown), exited with error code: 1
Please fix it up and finish by exiting the shell with one of these values:
    1  fixed, continue with next build command
    3  abort build

ct-ng:/tmp/toolchain-eglibc-201210/bld/.build/arm-unknown-linux-gnueabi/build/build-localedef> exit 1
exit

Continuing past the failed command.

[EXTRA]  Installing C library locales
[111:18] | /tmp/toolchain-eglibc-201210/tools/lib/ct-ng.hg+unknown-20121029.232826/scripts/functions: line 401: stop-: syntax error: operand expected (error token is "-")
[ERROR]
[ERROR]  >>
[ERROR]  >>  Build failed in step '(top-level)'
[ERROR]  >>
[ERROR]  >>  Error happened in: CT_EndStep[scripts/functions@401]
[ERROR]  >>        called from: do_libc_backend[scripts/build/libc/glibc-eglibc.sh-common@175]
[ERROR]  >>        called from: do_libc[scripts/build/libc/glibc-eglibc.sh-common@65]
[ERROR]  >>        called from: main[scripts/crosstool-NG.sh@609]
         /

Current command (unknown), exited with error code: 1
Please fix it up and finish by exiting the shell with one of these values:
    1  fixed, continue with next build command
    3  abort build

ct-ng:/tmp/toolchain-eglibc-201210/bld> less /tmp/toolchain-eglibc-201210/tools/lib/ct-ng.hg+unknown-20121029.232826/scripts/funct
ions
ct-ng:/tmp/toolchain-eglibc-201210/bld> exit 3
exit
/tmp/toolchain-eglibc-201210/tools/lib/ct-ng.hg+unknown-20121029.232826/scripts/functions: line 199: [: -le: unary operator expect
ed
[133:35] / /tmp/toolchain-eglibc-201210/tools/lib/ct-ng.hg+unknown-20121029.232826/scripts/functions: line 199: [: -le: unary oper
ator expected
[133:35] / /tmp/toolchain-eglibc-201210/tools/lib/ct-ng.hg+unknown-20121029.232826/scripts/functions: line 199: [: -le: unary oper
ator expected
[133:35] / /tmp/toolchain-eglibc-201210/tools/lib/ct-ng.hg+unknown-20121029.232826/scripts/functions: line 199: [: -le: unary oper
ator expected
[133:35] / /tmp/toolchain-eglibc-201210/tools/lib/ct-ng.hg+unknown-20121029.232826/scripts/functions: line 199: [: -le: unary oper
ator expected
[133:35] / /tmp/toolchain-eglibc-201210/tools/lib/ct-ng.hg+unknown-20121029.232826/scripts/functions: line 199: [: -le: unary oper
ator expected
[133:35] / /tmp/toolchain-eglibc-201210/tools/lib/ct-ng.hg+unknown-20121029.232826/scripts/functions: line 199: [: -le: unary oper
ator expected
[133:35] / /tmp/toolchain-eglibc-201210/tools/lib/ct-ng.hg+unknown-20121029.232826/scripts/functions: line 199: [: -le: unary oper
ator expected
[INFO ]  =================================================================
[INFO ]  Installing final compiler
[EXTRA]    Configuring final compiler
[EXTRA]    Building final compiler
...
[INFO ]  Build completed at 20121030.015413


--
For unsubscribe information see http://sourceware.org/lists.html#faq

scripts/functions: fix endless loop in debug-shell with IO redirection

[Yann E. MORIN]

Johannes, All,

Your patch:
    scripts/functions: fix endless loop in debug-shell with IO redirection

has been applied as: #5c67476c7342
    http://crosstool-ng.org/hg/crosstool-ng/rev/5c67476c7342

Thank you!

Regards,
Yann E. MORIN.



--
For unsubscribe information see http://sourceware.org/lists.html#faq

scripts/functions: use patch -i instead of IO redirection

[Yann E. MORIN]

Johannes, All,

Your patch:
    scripts/functions: use patch -i instead of IO redirection

has been applied as: #d1766c2273d1
    http://crosstool-ng.org/hg/crosstool-ng/rev/d1766c2273d1

Thank you!

Regards,
Yann E. MORIN.



--
For unsubscribe information see http://sourceware.org/lists.html#faq