From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fgw22-4.mail.saunalahti.fi (fgw22-4.mail.saunalahti.fi [62.142.5.109]) by sourceware.org (Postfix) with ESMTPS id D8F723857010 for ; Tue, 29 Sep 2020 07:04:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D8F723857010 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=wippies.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kai.ruottu@wippies.com Received: from [10.0.0.65] (mobile-access-5d6a5d-213.dhcp.inet.fi [93.106.93.213]) by fgw22.mail.saunalahti.fi (Halon) with ESMTPSA id 05ae023c-0222-11eb-88cb-005056bdf889; Tue, 29 Sep 2020 10:04:32 +0300 (EEST) Subject: Re: GCC cross-compiler errors To: Richard Earnshaw , William Gregorio , gcc-help@gcc.gnu.org References: From: Kai Ruottu Message-ID: Date: Tue, 29 Sep 2020 10:04:31 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00, HTML_MESSAGE, KAM_DMARC_STATUS, KAM_SHORT, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gcc-help@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-help mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2020 07:04:38 -0000 Richard Earnshaw kirjoitti 28.9.2020 klo 19.46: > On 25/09/2020 14:12, William Gregorio via Gcc-help wrote: >> Hi, >> >> I'm trying to build a gcc cross-compiler from source, and whenever I invoke >> make it results in an error. I'd appreciate any help! Feel free to request >> any more details needed. >> >> ./configure options >> --target=arm-none-eabi >> --prefix=/usr/bin/crossbuild >> --without-headers >> --enable-multilib >> --with-multilib=armv7e-m >> --with-gnu-as >> --with-gnu-ld >> --with-dwarf2 >> --with-newlib >> --with-system-zlib >> --without-libffi >> --disable-decimal-float >> --disable-nls >> --enable-languages="c,c++" >> --enable-interwork >> --disable-libstdcxx-pch >> --with-newlib >> >> >> make all Here are the true errors during the configure/build : >> configure: WARNING: stdbool.h: present but cannot be compiled >> configure: WARNING: stdbool.h: check for missing prerequisite headers? >> checking for stdbool.h... no >> configure: WARNING: stdalign.h: present but cannot be compiled >> configure: WARNING: stdalign.h: check for missing prerequisite headers? >> checking for stdalign.h... no >> Makefile:10307: recipe for target 'configure-target-libstdc++-v3' failed >> make[1]: *** [configure-target-libstdc++-v3] Error 1 I don't remember for what group these headers belong but one thing is sure in every GCC build, especially when trying to produce the extra target libraries like 'libstdc++-v3'.  What was told in the "Prerequisites" : https://gcc.gnu.org/install/prerequisites.html "In order to build GCC, the C standard library and headers must be present for all target variants for which target libraries will be built (and not only the variant of the host C++ compiler)." So where you did put the required 'arm-none-eabi' target headers? The option : |--without-headers|    Tells GCC not use any target headers from a libc when building a cross compiler.    When crossing to GNU/Linux, you need the headers so GCC can build the    exception handling for libgcc. Isn't maybe very clearly described. What means the "cross compiler"?  Is it the "xgcc", "cc1", "cc1plus" etc produced into the 'gcc' build directory?  Or does it also include all the target libraries produced with these executables?  The "Prerequisites" is more clear in this issue.  The : --with-newlib    Specifies that ‘newlib’ is being used as the target C library. This causes __eprintf    to be omitted from libgcc.a on the assumption that it will be provided by ‘newlib’. then only shows that one's aim is to use 'newlib' as the target C library. Normally this means that one builds 'newlib' at the same time with the GCC sources via providing the 'newlib' and 'libgloss' subdirs from the 'newlib-x.yz' sources in the main GCC source directory.  Via copying or symlinking. The GCC build will find the newlib headers automatically during the GCC and target libraries builds among the sources.  Trying to copy the headers from the newlib sources where they would be found is more hard ("--with-headers=").  If one already has an earlier toolchain for the target with "acid tested" C library, then not building one with the new GCC maybe is motivated. Only when one is sure that the newer GCC will produce working code. In this case one knows where the target headers are and can copy them or use them where they are (the $prefix used in configure is the same). >> Use a separate build area from your sources. Building inside the source >> tree is not supported. This is true but I'm not sure whether this was the case here. "Where are the target headers and where to put them" has been an eternal problem when people are building tools for embedded use.  And all kind of "conspiracy theories" about the GCC developers trying to get things complicated are spread in the net. Although the "Prerequisites" clearly tells : "To build all languages in a cross-compiler or other configuration where 3-stage bootstrap is not performed," people still believe in weird "multi-phase" build requirements in cross GCC builds. For instance that building newlib immediately with GCC doesn't work but one must first build a "bootstrap GCC", then newlib from sources with it and in stage 3 the "final GCC".