cross compiler host vs build

cross compiler host vs build

[dan clark]

During the configuration of gdb for cross compilation the configure 
command line can include:
--build, --host, --target.

The configure script in 6.0 checks if the host != target to decide if a
cross compiler should be used.  Based on the definitions in the
documentation the host is 'where gdb runs' and the target is 'where
program being debugged executes', neither of which have anything to do
what compiler is being used to build the code. Perhaps the decision on
when to use a cross compiler should be made based on when the 'build' is
not equal to the 'host' machine, thus requiring a cross compiler to
produce the binary. 

diff -r -c -N -p -x '*.orig' -x '*.rej' gdb-6.0-orig/configure gdb-6.0/configure
*** gdb-6.0-orig/configure	Tue Jun 17 19:25:31 2003
--- gdb-6.0/configure	Mon Dec 29 13:45:35 2003
*************** appdirs=""
*** 848,854 ****
  
  # Define is_cross_compiler to save on calls to 'test'.
  is_cross_compiler=
! if test x"${host}" = x"${target}" ; then
    is_cross_compiler=no
  else
    is_cross_compiler=yes
--- 848,854 ----
  
  # Define is_cross_compiler to save on calls to 'test'.
  is_cross_compiler=
! if test x"${host}" = x"${build}" ; then
    is_cross_compiler=no
  else
    is_cross_compiler=yes

-- 
Dan L. Clark       dlc@ncube.com    503/531-6432
nCUBE, 1825 NW 167th Place, Beaverton, OR  97006

Re: cross compiler host vs build

[Felix Lee]

dan clark <dlc@ncube.com>:
> The configure script in 6.0 checks if the host != target to decide if a
> cross compiler should be used.

no, it doesn't.  is_cross_compiler is a badly named variable.  it
means you're building a cross development gdb, and it doesn't
have anything to do with whether you're using a cross compiler to
build gdb.  (the variable name makes more sense when you have an
integrated gdb/gcc source tree.)

there are different tests elsewhere for build != host.

(note, configure is a file generated by autoconf.  patches should
be made to configure.in.)

I don't really see a reason for the variable is_cross_compiler
to exist.  the comment says
    # Define is_cross_compiler to save on calls to 'test'.
but it's usually used like this
    if test x${is_cross_compiler} != xno ; then
so it's not reducing the number of tests much.  I think directly
testing host = target would be clearer.
--

with-headers should be 'build' != 'host'

[dan clark]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1943 bytes --]

Thank you for the clarification.  I agree that a fix should be 
applied to configure.in. Since the tar file includes both 
configure and configure.in the configure script must also be patched in 
attempts to use the 6.0 distribution as provided.

The use of is_cross_compiler does seem to be overloaded.  In particular, 
it is subsequently used for determining the skipdirs, determining if 
newlib should be built, and if it is OK to have the 'with_headers' value 
defined, the later of which is most problematic.  If the 'build' != 'host' 
then it is likely that 'with_headers' will be defined.  But it may very 
well be that 'host' == 'target' in this case.  The fix I proposed is a bit 
heavy handed, perhaps the more appropriate way of dealing with this 
issue is the refine the test which results in the error:
"*** --with-headers is only supported when cross compiling"

The resulting revised patch is attached for clarity.
dan

On Wed, 28 Jan 2004, Felix Lee wrote:

> dan clark <dlc@ncube.com>:
> > The configure script in 6.0 checks if the host != target to decide if a
> > cross compiler should be used.
> 
> no, it doesn't.  is_cross_compiler is a badly named variable.  it
> means you're building a cross development gdb, and it doesn't
> have anything to do with whether you're using a cross compiler to
> build gdb.  (the variable name makes more sense when you have an
> integrated gdb/gcc source tree.)
> 
> there are different tests elsewhere for build != host.
> 
> (note, configure is a file generated by autoconf.  patches should
> be made to configure.in.)
> 
> I don't really see a reason for the variable is_cross_compiler
> to exist.  the comment says
>     # Define is_cross_compiler to save on calls to 'test'.
> but it's usually used like this
>     if test x${is_cross_compiler} != xno ; then
> so it's not reducing the number of tests much.  I think directly
> testing host = target would be clearer.
> --
> 
> 



[-- Attachment #2: diff --]
[-- Type: TEXT/PLAIN, Size: 1612 bytes --]

*** configure	Thu Jan 29 08:55:35 2004
--- configure.orig	Thu Jan 29 08:56:01 2004
*************** copy_dirs=
*** 1603,1609 ****
  # Handle --with-headers=XXX.  If the value is not "yes", the contents of
  # the named directory are copied to $(tooldir)/sys-include.
  if test x"${with_headers}" != x ; then
!   if test x"${host}" = x"${build}"; then
      echo 1>&2 '***' --with-headers is only supported when cross compiling
      exit 1
    fi
--- 1603,1609 ----
  # Handle --with-headers=XXX.  If the value is not "yes", the contents of
  # the named directory are copied to $(tooldir)/sys-include.
  if test x"${with_headers}" != x ; then
!   if test x${is_cross_compiler} = xno ; then
      echo 1>&2 '***' --with-headers is only supported when cross compiling
      exit 1
    fi
*** configure.in	Thu Jan 29 08:57:13 2004
--- configure.in.orig	Thu Jan 29 08:56:55 2004
*************** copy_dirs=
*** 917,923 ****
  # Handle --with-headers=XXX.  If the value is not "yes", the contents of
  # the named directory are copied to $(tooldir)/sys-include.
  if test x"${with_headers}" != x ; then
!   if test x"${host}" = x"${build}"; then
      echo 1>&2 '***' --with-headers is only supported when cross compiling
      exit 1
    fi
--- 917,923 ----
  # Handle --with-headers=XXX.  If the value is not "yes", the contents of
  # the named directory are copied to $(tooldir)/sys-include.
  if test x"${with_headers}" != x ; then
!   if test x${is_cross_compiler} = xno ; then
      echo 1>&2 '***' --with-headers is only supported when cross compiling
      exit 1
    fi

Re: with-headers should be 'build' != 'host'

[Daniel Jacobowitz]

On Thu, Jan 29, 2004 at 08:59:55AM -0800, dan clark wrote:
> Thank you for the clarification.  I agree that a fix should be 
> applied to configure.in. Since the tar file includes both 
> configure and configure.in the configure script must also be patched in 
> attempts to use the 6.0 distribution as provided.
> 
> The use of is_cross_compiler does seem to be overloaded.  In particular, 
> it is subsequently used for determining the skipdirs, determining if 
> newlib should be built, and if it is OK to have the 'with_headers' value 
> defined, the later of which is most problematic.  If the 'build' != 'host' 
> then it is likely that 'with_headers' will be defined.  But it may very 
> well be that 'host' == 'target' in this case.  The fix I proposed is a bit 
> heavy handed, perhaps the more appropriate way of dealing with this 
> issue is the refine the test which results in the error:
> "*** --with-headers is only supported when cross compiling"
> 
> The resulting revised patch is attached for clarity.

First of all, this is off-topic for gdb-patches; --with-headers doesn't
affect GDB at all.  Redirecting to gcc@.

Secondly, you're still confused about --build, --host, and --target. 
If $build != $host == $target, you are building a native toolchain for
another system.  This has never been especially well supported, but
--with-headers is definitely not the right way to do it.  The copied
headers are used by the built gcc/xgcc, not by the compiler used to
build GCC.


> dan
> 
> On Wed, 28 Jan 2004, Felix Lee wrote:
> 
> > dan clark <dlc@ncube.com>:
> > > The configure script in 6.0 checks if the host != target to decide if a
> > > cross compiler should be used.
> > 
> > no, it doesn't.  is_cross_compiler is a badly named variable.  it
> > means you're building a cross development gdb, and it doesn't
> > have anything to do with whether you're using a cross compiler to
> > build gdb.  (the variable name makes more sense when you have an
> > integrated gdb/gcc source tree.)
> > 
> > there are different tests elsewhere for build != host.
> > 
> > (note, configure is a file generated by autoconf.  patches should
> > be made to configure.in.)
> > 
> > I don't really see a reason for the variable is_cross_compiler
> > to exist.  the comment says
> >     # Define is_cross_compiler to save on calls to 'test'.
> > but it's usually used like this
> >     if test x${is_cross_compiler} != xno ; then
> > so it's not reducing the number of tests much.  I think directly
> > testing host = target would be clearer.
> > --
> > 
> > 
> 
> 

Content-Description: diff
> *** configure	Thu Jan 29 08:55:35 2004
> --- configure.orig	Thu Jan 29 08:56:01 2004
> *************** copy_dirs=
> *** 1603,1609 ****
>   # Handle --with-headers=XXX.  If the value is not "yes", the contents of
>   # the named directory are copied to $(tooldir)/sys-include.
>   if test x"${with_headers}" != x ; then
> !   if test x"${host}" = x"${build}"; then
>       echo 1>&2 '***' --with-headers is only supported when cross compiling
>       exit 1
>     fi
> --- 1603,1609 ----
>   # Handle --with-headers=XXX.  If the value is not "yes", the contents of
>   # the named directory are copied to $(tooldir)/sys-include.
>   if test x"${with_headers}" != x ; then
> !   if test x${is_cross_compiler} = xno ; then
>       echo 1>&2 '***' --with-headers is only supported when cross compiling
>       exit 1
>     fi
> *** configure.in	Thu Jan 29 08:57:13 2004
> --- configure.in.orig	Thu Jan 29 08:56:55 2004
> *************** copy_dirs=
> *** 917,923 ****
>   # Handle --with-headers=XXX.  If the value is not "yes", the contents of
>   # the named directory are copied to $(tooldir)/sys-include.
>   if test x"${with_headers}" != x ; then
> !   if test x"${host}" = x"${build}"; then
>       echo 1>&2 '***' --with-headers is only supported when cross compiling
>       exit 1
>     fi
> --- 917,923 ----
>   # Handle --with-headers=XXX.  If the value is not "yes", the contents of
>   # the named directory are copied to $(tooldir)/sys-include.
>   if test x"${with_headers}" != x ; then
> !   if test x${is_cross_compiler} = xno ; then
>       echo 1>&2 '***' --with-headers is only supported when cross compiling
>       exit 1
>     fi


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: with-headers should be 'build' != 'host'

[Felix Lee]

I use --with-headers when build == host and host != target.
applying your patch would break that.
--

Re: with-headers should be 'build' != 'host'

[Ian Lance Taylor]

Daniel Jacobowitz <drow@mvista.com> writes:

> Secondly, you're still confused about --build, --host, and --target. 
> If $build != $host == $target, you are building a native toolchain for
> another system.  This has never been especially well supported, but
> --with-headers is definitely not the right way to do it.  The copied
> headers are used by the built gcc/xgcc, not by the compiler used to
> build GCC.

Hmmm, I don't follow here.  I seem to recall that I wrote
--with-header specifically to support the case of $build != $host ==
$target.  So I'm surprised that you say that --with-headers is not the
right approach.  You're suppose to use --with-headers for the header
files for $target.  It's not wrong to use it when $host == $target.

But I'm probably misunderstanding something.

Ian

Re: with-headers should be 'build' != 'host'

[Felix Lee]

it seems to me that --with-headers (and related options) can be
useful in any case where build != target
there are three possibilities
  - building a cross tool, like linux/linux/solaris
  - cross-building a native tool, like linux/solaris/solaris
  - cross-building a cross tool, like linux/cygwin/solaris

maybe it would be helpful to put the word 'target' in the option?
  --with-target-sysroot
  --with-host-sysroot
etc.
--