On Mon, Apr 20, 2020 at 02:04:32PM +0100, Leif Lindholm wrote:
> On Fri, Apr 10, 2020 at 05:05:48 -0700, Daniel Kiper wrote:
> > On Tue, Apr 07, 2020 at 12:16:09PM +0100, Leif Lindholm wrote:
> > > On Fri, Apr 03, 2020 at 14:45:02 +0200, Daniel Kiper wrote:
> > > > ..to reflect the GRUB build reality in them.
> > > >
> > > > Additionally, fix ./configure command example formatting in INSTALL 
> > > > file.
> > > >
> > > > Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
> > > > ---
> > > >  INSTALL      | 51 +++++++++++++++++++++++++++------------------------
> > > >  configure.ac | 10 ++++++----
> > > >  2 files changed, 33 insertions(+), 28 deletions(-)
> > > >
> > > > diff --git a/INSTALL b/INSTALL
> > > > index 8acb40902..d1b3bb60e 100644
> > > > --- a/INSTALL
> > > > +++ b/INSTALL
> > > > @@ -160,12 +160,12 @@ For this example the configure line might look 
> > > > like (more details below)
> > > >  (some options are optional and included here for completeness but some 
> > > > rarely
> > > >  used options are omitted):
> > > >
> > > > -./configure BUILD_CC=gcc BUILD_PKG_CONFIG=pkg-config 
> > > > --host=amd64-linux-gnu
> > > > -CC=amd64-linux-gnu-gcc CFLAGS="-g -O2" 
> > > > PKG_CONFIG=amd64-linux-gnu-pkg-config
> > > > ---target=arm --with-platform=uboot TARGET_CC=arm-elf-gcc
> > > > -TARGET_CFLAGS="-Os -march=armv6" TARGET_CCASFLAGS="-march=armv6"
> > > > -TARGET_OBJCOPY="arm-elf-objcopy" TARGET_STRIP="arm-elf-strip"
> > > > -TARGET_NM=arm-elf-nm TARGET_RANLIB=arm-elf-ranlib LEX=gflex
> > > > +./configure BUILD_CC=gcc BUILD_PKG_CONFIG=pkg-config 
> > > > --host=amd64-linux-gnu \
> > > > +  CC=amd64-linux-gnu-gcc CFLAGS="-g -O2" 
> > > > PKG_CONFIG=amd64-linux-gnu-pkg-config \
> > > > +  --target=arm --with-platform=uboot TARGET_CC=arm-elf-gcc \
> > > > +  TARGET_CFLAGS="-Os -march=armv6" TARGET_CCASFLAGS="-march=armv6" \
> > > > +  TARGET_OBJCOPY="arm-elf-objcopy" TARGET_STRIP="arm-elf-strip" \
> > > > +  TARGET_NM=arm-elf-nm TARGET_RANLIB=arm-elf-ranlib LEX=gflex
> > >
> > > So ... probably should have looked more properly at this round 1.
> > >
> > > If we are updating this guidance, should we bring it up to date as
> > > well?
> > >
> > > Now we have uefi support in u-boot, the "uboot" platform is the
> > > exception rather than the norm. It'd be better to specify
> > > --with-platform=efi.
> > >
> > > Secondly, these appear to be flags used when
> > > building GRUB for Raspberry Pi 1; -march-armv6 is quite outdated and
> > > could be dropped. (Although I guess it becomes more relevant when seen
> > > in combination with TARGET_CCASFLAGS.)
> >
> > What do you think about this:
> >
> > ./configure --host=x86_64-linux-gnu --target=aarch64-linux-gnu \
> >   --with-platform=efi BUILD_CC=gcc BUILD_PKG_CONFIG=pkg-config \
> >   HOST_CC=x86_64-linux-gnu-gcc HOST_CFLAGS='-g -O2' \
> >   PKG_CONFIG=x86_64-linux-gnu-pkg-config TARGET_CC=aarch64-linux-gnu-gcc \
> >   TARGET_CFLAGS='-Os -march=armv8-a' TARGET_CCASFLAGS='-march=armv8-a' \
> >   TARGET_OBJCOPY=aarch64-linux-gnu-objcopy \
> >   TARGET_STRIP=aarch64-linux-gnu-strip TARGET_NM=aarch64-linux-gnu-nm \
> >   TARGET_RANLIB=aarch64-linux-gnu-ranlib LEX=flex
>
> I mean, it's less dated, but it also makes less sense than the
> original - an aarch64-linux-gnu-gcc toolchain is very highly likely to
> default to -march=armv8-a. It would make more sense to specify
> something like -march=armv8.4a.

OK, so, I will change -march to armv8.4a.

> > > Could we add a sentence here going (if switching to efi for the platform):
> > > "Normally, for building a grub on amd64 with tools to run on amd64 to
> > > generate images to run on arm, using your Linux distribution's
> > > packaged cross compiler, the following would suffice:
> > >
> > > ./configure --target=arm-linux-gnueabihf --with-platform=efi"
> >
> > ./configure --target=aarch64-linux-gnu --with-platform=efi
>
> Again, the original actually made more sense - arm64 only supports efi.

Yeah, so, let's stick with currently existing example.

> > > >  You need to use following options to specify tools and platforms. For 
> > > > minimum
> > > >  version look at prerequisites. All tools not mentioned in this section 
> > > > under
> > > > @@ -182,28 +182,31 @@ corresponding platform are not needed for the 
> > > > platform in question.
> > > >
> > > >    - For host
> > > >      1. --host= to autoconf name of host.
> > > > -    2. CC= for gcc able to compile for host
> > > > -    3. HOST_CFLAGS= for C options for host.
> > > > -    4. HOST_CPPFLAGS= for C preprocessor options for host.
> > > > -    5. HOST_LDFLAGS= for linker options for host.
> > > > -    6. PKG_CONFIG= for pkg-config for host (optional).
> > > > -    7. Libdevmapper if any must be in standard linker folders 
> > > > (-ldevmapper) (optional).
> > > > -    8. Libfuse if any must be in standard linker folders (-lfuse) 
> > > > (optional).
> > > > -    9. Libzfs if any must be in standard linker folders (-lzfs) 
> > > > (optional).
> > > > -    10. Liblzma if any must be in standard linker folders (-llzma) 
> > > > (optional).
> > > > +    2. CC= for gcc able to compile for host and target.
> > >
> > > But this is incorrect? Apart from where HOST == TARGET? And goes
> > > against the example updated above.
> > > Am I missing something?
> >
> > It is correct, CC applies for host and target...
>
> So why do we have TARGET_CC and HOST_CC?
>
> My understanding is:
> - CC sets the default compilet binary, used for BUILD, HOST and TARGET
>   unless overridden for each of these.

Nope, just HOST_CC and TARGET_CC. You can override CC using TARGET_CC and
HOST_CC respectively. Order in configure command line does not matter.

> - The value of BUILD_CC is used as default for HOST_CC unless
>   HOST_CC is explicitly specified.

Nope, it is not.

> - The value of HOST_CC is used as the default for TARGET_CC, where *it*
>   is not explicitly specified.

Nope, it is not.

> Either my understanding here is incorrect, or these changes make the
> text more rather than less misleading.

Sorry but I am not sure what is unclear after my changes.

Daniel

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Reply via email to