Building a cross compiler fails due to hardcoding host=target in gcc/Makefile.in

Building a cross compiler fails due to hardcoding host=target in gcc/Makefile.in

[William ML Leslie]

Greetings,

Please keep me CC'd as I'm not subscribed.

I've been trying to build a cross compilation toolchain (for a new OS)
and ran into a confusing error while building gcc 10.2.0.  While
building libgcc, it fails running libgcc/config.host as it gets passed
my target instead of the actual host.  I traced this back to the root
Makefile.in, for which the `configure-target-libgcc` rule ends with:

    CONFIG_SITE=no-such-file $(SHELL) \
      $$s/$$module_srcdir/configure \
      --srcdir=$${topdir}/$$module_srcdir \
      $(TARGET_CONFIGARGS) --build=${build_alias} --host=${target_alias} \
      --target=${target_alias}  \
      || exit 1

This is probably someone trying to be helpful when building a Canadian
Cross (host == target), however there is already a host_alias variable
defined at the very top of `Makefile.in`.  When using a traditional
cross compiler, the host is equal to the build machine; but the
makefile ignores this case.

Have I missed something, or should I send a patch for this?

Snippet of make output where I hit this:

Checking multilib configuration for libgcc...
mkdir -p -- i386-unknown-capros/libgcc
Configuring in i386-unknown-capros/libgcc
...
checking for target glibc version... 0.0
*** Configuration i386-unknown-capros not supported
Makefile:12629: recipe for target 'configure-target-libgcc' failed
make[1]: *** [configure-target-libgcc] Error 1
make[1]: Leaving directory '/extra/wleslie/xenv2/build/gcc-10.2.0/build-capros'
Makefile:954: recipe for target 'all' failed
make: *** [all] Error 2

-- 
William Leslie

Q: What is your boss's password?
A: "Authentication", clearly

Notice:
Likely much of this email is, by the nature of copyright, covered
under copyright law.  You absolutely MAY reproduce any part of it in
accordance with the copyright law of the nation you are reading this
in.  Any attempt to DENY YOU THOSE RIGHTS would be illegal without
prior contractual agreement.

Re: Building a cross compiler fails due to hardcoding host=target in gcc/Makefile.in

[William ML Leslie]

Sorry, i found bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94761 so
I'll continue there tomorrow.

On Fri, 16 Oct 2020, 11:39 pm William ML Leslie, <
william.leslie.ttg@gmail.com> wrote:

> Greetings,
>
> Please keep me CC'd as I'm not subscribed.
>
> I've been trying to build a cross compilation toolchain (for a new OS)
> and ran into a confusing error while building gcc 10.2.0.  While
> building libgcc, it fails running libgcc/config.host as it gets passed
> my target instead of the actual host.  I traced this back to the root
> Makefile.in, for which the `configure-target-libgcc` rule ends with:
>
>     CONFIG_SITE=no-such-file $(SHELL) \
>       $$s/$$module_srcdir/configure \
>       --srcdir=$${topdir}/$$module_srcdir \
>       $(TARGET_CONFIGARGS) --build=${build_alias} --host=${target_alias} \
>       --target=${target_alias}  \
>       || exit 1
>
> This is probably someone trying to be helpful when building a Canadian
> Cross (host == target), however there is already a host_alias variable
> defined at the very top of `Makefile.in`.  When using a traditional
> cross compiler, the host is equal to the build machine; but the
> makefile ignores this case.
>
> Have I missed something, or should I send a patch for this?
>
> Snippet of make output where I hit this:
>
> Checking multilib configuration for libgcc...
> mkdir -p -- i386-unknown-capros/libgcc
> Configuring in i386-unknown-capros/libgcc
> ...
> checking for target glibc version... 0.0
> *** Configuration i386-unknown-capros not supported
> Makefile:12629: recipe for target 'configure-target-libgcc' failed
> make[1]: *** [configure-target-libgcc] Error 1
> make[1]: Leaving directory
> '/extra/wleslie/xenv2/build/gcc-10.2.0/build-capros'
> Makefile:954: recipe for target 'all' failed
> make: *** [all] Error 2
>
> --
> William Leslie
>
> Q: What is your boss's password?
> A: "Authentication", clearly
>
> Notice:
> Likely much of this email is, by the nature of copyright, covered
> under copyright law.  You absolutely MAY reproduce any part of it in
> accordance with the copyright law of the nation you are reading this
> in.  Any attempt to DENY YOU THOSE RIGHTS would be illegal without
> prior contractual agreement.
>

Re: Building a cross compiler fails due to hardcoding host=target in gcc/Makefile.in

[William ML Leslie]

> On Fri, 16 Oct 2020, 11:39 pm William ML Leslie, <william.leslie.ttg@gmail.com> wrote:
>>
>> Greetings,
>>
>> Please keep me CC'd as I'm not subscribed.
>>
>> I've been trying to build a cross compilation toolchain (for a new OS)
>> and ran into a confusing error while building gcc 10.2.0.  While
>> building libgcc, it fails running libgcc/config.host as it gets passed
>> my target instead of the actual host.  I traced this back to the root
>> Makefile.in, for which the `configure-target-libgcc` rule ends with:
>>
>>     CONFIG_SITE=no-such-file $(SHELL) \
>>       $$s/$$module_srcdir/configure \
>>       --srcdir=$${topdir}/$$module_srcdir \
>>       $(TARGET_CONFIGARGS) --build=${build_alias} --host=${target_alias} \
>>       --target=${target_alias}  \
>>       || exit 1
>>
>> This is probably someone trying to be helpful when building a Canadian
>> Cross (host == target), however there is already a host_alias variable
>> defined at the very top of `Makefile.in`.  When using a traditional
>> cross compiler, the host is equal to the build machine; but the
>> makefile ignores this case.
>>
>> Have I missed something, or should I send a patch for this?
>>

So this turned out to be PEBKAC; I'll describe further in detail in
case anybody else is hitting this.

Libgcc describes some compiler built-ins, standard features etc of the
compiler, things which are linked in with programs on the target
machine.  So, it makes sense to have --host=target here.  That is, the
code within libgcc runs only on the target, so the target /is/ the
host.  This is also true for many of the other libraries built along
with gcc.

Builds I tried failed here for two possible reasons.  Since I was
trying to target a new OS, there was no configuration for this "host"
in libgcc/configure.host.  If you're starting out on common
architectures and don't need e.g. PIC support, you can reasonably
leave these blank, but check other systems on your CPU family for what
is commonly included.  The `tmake_file` variables used reference files
in libgcc/config/.  If you're porting an older toolchain like I am,
you might be providing your own crt files; if you wanted to integrate
these, this might be a good place to do so as quite a lot of
functionality is available.

The other reason I found while attempting to diagnose the issue by
building other cross compilers is that you'll need system headers if
you're trying to build a gcc to target an operating system (as opposed
to a bare machine such as mips64eb-elf).  For example,
ia64-unknown-linux-gnu expects certain system headers to be available.

-- 
William Leslie

Q: What is your boss's password?
A: "Authentication", clearly

Notice:
Likely much of this email is, by the nature of copyright, covered
under copyright law.  You absolutely MAY reproduce any part of it in
accordance with the copyright law of the nation you are reading this
in.  Any attempt to DENY YOU THOSE RIGHTS would be illegal without
prior contractual agreement.