Robert Millan wrote:
Hi,
Based on the description of host/target triplets in configure.ac:
dnl build -- the environment for building GRUB
dnl host -- the environment for running utilities
dnl target -- the environment for running GRUB
it seems that target_os is an oxymoron. There's no OS in the environment
where GRUB will run (well, there's the firmware, but we already use
target_vendor for that, and _os has a well-defined meaning).
Attached patch fixes that by supressing all references to target_os, and
replacing them with host_os where suitable.
Christian: since this mostly affects Cygwin, could you verify that it doesn't
cause breakage before I commit it?
Hi Robert,
thanks for sending the patch first. Cygwin build looks good.
But even if GRUB itself is build for some $target_cpu-$target_vendor
(i386-pc), the target_os is not useless if cross-compilation support is
desired:
- GRUB tools like grub-setup are build for the target_os
- Package structure may depend on target_os.
- The gcc code generator may emit special code tailored for the assumed
target_os
Examples:
Stack frame checks
Nested function trampolines (__enable_execute_stack())
Unfortunately, gcc has no '-fno_os' option to specify the bare CPU as
target.
Fortunately, all current issues can be handled by autoconf checks.
AC_MSG_CHECKING([for command to convert module to ELF format])
-case "${host_os}:${target_os}" in
- cygwin:cygwin) TARGET_OBJ2ELF='grub-pe2elf' ;;
+case "${host_os}" in
+ cygwin) TARGET_OBJ2ELF='grub-pe2elf' ;;
*) ;;
esac
This won't work for a Linux cross compiler hosted on Cygwin. It would
emit ELF format and does not need pe2elf.
But all this is theoretical unless cross compilation is really needed.
Christian
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
