Fix installation of crosstool-ng libraries to target

When using the crosstool-ng toolchain option, the libc libraries were not installed to target.
Buildroot calls the show-tuple function to determine the directory to copy from, and it seems
that outputs the result to stderr instead of stdout

Signed-off-by: Floris Bos <bos@je-eigen-domein.nl>
---
 toolchain/toolchain-crosstool-ng/crosstool-ng.mk |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Floris, All,

On Sunday 06 January 2013 Floris Bos wrote:
> When using the crosstool-ng toolchain option, the libc libraries were not installed to target.
> Buildroot calls the show-tuple function to determine the directory to copy from, and it seems
> that outputs the result to stderr instead of stdout
> 
> Signed-off-by: Floris Bos <bos@je-eigen-domein.nl>
> ---
>  toolchain/toolchain-crosstool-ng/crosstool-ng.mk |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/toolchain/toolchain-crosstool-ng/crosstool-ng.mk b/toolchain/toolchain-crosstool-ng/crosstool-ng.mk
> index 6f81e30..553c9ee 100644
> --- a/toolchain/toolchain-crosstool-ng/crosstool-ng.mk
> +++ b/toolchain/toolchain-crosstool-ng/crosstool-ng.mk
> @@ -66,7 +66,7 @@ endif
>  # Actual copy
>  $(STAMP_DIR)/ct-ng-toolchain-installed: $(STAMP_DIR)/ct-ng-toolchain-built
>  	$(Q)mkdir -p $(TARGET_DIR)/lib
> -	$(Q)CTNG_TUPLE="$$( $(call ctng,show-tuple) )";                     \
> +	$(Q)CTNG_TUPLE="$$( $(call ctng,show-tuple 2>&1) )";                \

Indeed, that's going to stderr. That's a but in crostool-NG, it should go
to stdout. Will fix in ct-ng.

In the meantime:
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

Regards,
Yann E. MORIN.

>>>>> "Floris" == Floris Bos <bos@je-eigen-domein.nl> writes:

 Floris> When using the crosstool-ng toolchain option, the libc
 Floris> libraries were not installed to target.  Buildroot calls the
 Floris> show-tuple function to determine the directory to copy from,
 Floris> and it seems that outputs the result to stderr instead of
 Floris> stdout

Committed, thanks.

>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:

Hi,

 >> -	$(Q)CTNG_TUPLE="$$( $(call ctng,show-tuple) )";                     \
 >> +	$(Q)CTNG_TUPLE="$$( $(call ctng,show-tuple 2>&1) )";                \

 Yann> Indeed, that's going to stderr. That's a but in crostool-NG, it
 Yann> should go to stdout. Will fix in ct-ng.

 Yann> In the meantime:
 Yann> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

Thanks. Does this mean the internal ctng backend has never worked at runtime?

Peter, All,

On Sunday 06 January 2013 Peter Korsgaard wrote:
> >>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:
>  >> -	$(Q)CTNG_TUPLE="$$( $(call ctng,show-tuple) )";                     \
>  >> +	$(Q)CTNG_TUPLE="$$( $(call ctng,show-tuple 2>&1) )";                \
> 
>  Yann> Indeed, that's going to stderr. That's a but in crostool-NG, it
>  Yann> should go to stdout. Will fix in ct-ng.
> 
>  Yann> In the meantime:
>  Yann> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
> 
> Thanks. Does this mean the internal ctng backend has never worked at runtime?

Nope, it's only since the last update.

Long story made short:
  - ct-ng uses some fd redirection for its log
  - previously, fd #7 was not used for this
  - showtuple redirected fd #7 to stdout, and it worked
  - last ct-ng version introduced the 'debug-shell' feature
  - the debug-shell redirects fd #7 to stderr
  - and it breaks now.

I did not catch this, as I did not do the update to ct-ng in Buildroot,
so did not run any test. Also, I'm currently using pre-built toolchains
for my current experiments, so it slipped through...

I've already fixed it in ct-ng right now, and I'm testing integration
in Buildroot (first test just finished OK).

I will push an updated patch later today.

It also means that people seldom use the ct-ng backend, and people either
use the internal backend, or external toolchains. So, a couple of questions:
  - should we finally switch over to using the ct-ng backend by default?
  - is it worth maintaing the ct-ng backend at all?

Regards,
Yann E. MORIN.

Dear Yann E. MORIN,

On Sun, 6 Jan 2013 12:29:18 +0100, Yann E. MORIN wrote:

> It also means that people seldom use the ct-ng backend, and people either
> use the internal backend, or external toolchains. So, a couple of questions:
>   - should we finally switch over to using the ct-ng backend by default?
>   - is it worth maintaing the ct-ng backend at all?

As far as autobuilders are concerned, the ct-ng backend is tested, but
this bug was apparently not breaking the build, but only the execution.
Therefore, it was not detected by the autobuilders.

Thomas

>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:

Hi,

 Yann> It also means that people seldom use the ct-ng backend, and
 Yann> people either use the internal backend, or external
 Yann> toolchains. So, a couple of questions:

 Yann>   - should we finally switch over to using the ct-ng backend by default?
 Yann>   - is it worth maintaing the ct-ng backend at all?

I think we all agree that the long term plan is to deprecate the
internal toolchain option. I do think that it's getting a bit late for
the current cycle, but lets discuss at the dev day and change the
default for the 2013.05 cycle if everyone agrees.