All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Yoshinori K. Okuji" <okuji@enbug.org>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: [PATCH] Fix target tool check logic
Date: Sat, 11 Apr 2009 19:19:22 +0900	[thread overview]
Message-ID: <200904111919.22519.okuji@enbug.org> (raw)
In-Reply-To: <20090411005826.oahebrl8ys0w0o0k-cebfxv@webmail.spamcop.net>

On Saturday 11 April 2009 13:58:26 Pavel Roskin wrote:
> Hello!
>
> I promised this patch long ago, but didn't have a chance to implement
> and test it.  This patch would help users test GRUB using
> cross-compilers.  Many users would prefer to compile native GRUB
> utilities (grub-mkimage etc) but create the bootloader for another
> platform.  This is currently impossible.  To compile the bootloader
> for a foreign architecture, you have to cross-compile the GRUB
> utilities.
>
> The current logic is broken.  The check for the target compiler is
> made if the canonical name for the build and the host are identical,
> that is if we are cross-compiling the GRUB utilities.  The matches the
> incorrect comment, but doesn't match the intention of the code.
>
> The intention is to check for the target compiler and other tools
> after we have already found the tools for compiling for the host.
>
> If the target has not been specified on the command line, there is no
> need to look for the target tools.  It is assumed that the host and
> the target are the same, whether we are cross-compiling or not.  The
> host tools can be used.  The target specified on the command line is
> stored in $target_alias.  Thus, if $target_alias is empty, we don't
> check for the target tools.
>
> Further, if somebody specified the host and the target in the same
> way, there is no need to check for the target tools.  They will be the
> same.  Some package build system like to specify all possible
> switches, so they will be happy.
>
> However, if the host and the target are specified in different ways on
> the command line, we need to check for the target tools.  That
> includes the case when the host has not been specified at all.
>
> Even if the canonical names are the same, we should check for the
> target tools.  If $host_alias and $target_alias are different,
> configure can find different compilers.  For example, if somebody runs
>
> ./configure --host=powerpc-linux --target=powerpc-linux-uclibc
>
> and both powerpc-linux-gcc and powerpc-linux-uclibc-gcc are present in
> $PATH, the former would be used for the host and the later for the
> target.  Generally, if the user took care to specify different values,
> we should take care not to ignore that.
>
> ChangeLog:
>          * configure.ac: Change the logic when we check for target tools.
>          Do it when the target is specified and it's different from the
>          specified value of the host.
>
> --- configure.ac
> +++ configure.ac
> @@ -231,8 +231,8 @@
>   AC_SUBST(TARGET_OBJ2ELF)
>   AC_MSG_RESULT([$TARGET_OBJ2ELF])
>
> -# For cross-compiling.
> -if test "x$build" != "x$host"; then
> +# Find tools for the target.
> +if test -n "$target_alias" && test "x$host_alias" != "x$target_alias";

"test -n" should be avoided. Maybe this is not necessary nowadays, but my old 
lesson was to use "test x$target_alias != x" instead for portability. 
Well, "!=" was not very portable, either, maybe.

> then # XXX this depends on the implementation of autoconf!
>     tmp_ac_tool_prefix="$ac_tool_prefix"
>     ac_tool_prefix=$target_alias-


Regards,
Okuji



  reply	other threads:[~2009-04-11 10:19 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-11  4:58 [PATCH] Fix target tool check logic Pavel Roskin
2009-04-11 10:19 ` Yoshinori K. Okuji [this message]
2009-04-11 13:16   ` Pavel Roskin
2009-04-14 15:45     ` Yoshinori K. Okuji
2009-04-15  0:31       ` Pavel Roskin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200904111919.22519.okuji@enbug.org \
    --to=okuji@enbug.org \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.