grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Fix target tool check logic


From: Yoshinori K. Okuji
Subject: Re: [PATCH] Fix target tool check logic
Date: Sat, 11 Apr 2009 19:19:22 +0900
User-agent: KMail/1.9.10

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 via email to

[Prev in Thread] Current Thread [Next in Thread]