From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mengyan1223.wang (mengyan1223.wang [89.208.246.23]) by sourceware.org (Postfix) with ESMTPS id 3D0903858C60 for ; Mon, 10 Jan 2022 17:16:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3D0903858C60 Received: from localhost.localdomain (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-384) server-digest SHA384) (Client did not present a certificate) (Authenticated sender: xry111@mengyan1223.wang) by mengyan1223.wang (Postfix) with ESMTPSA id 96597660C4; Mon, 10 Jan 2022 12:16:06 -0500 (EST) Message-ID: Subject: Re: Compiling GCC 11 for Windows targeting ARM on Linux From: Xi Ruoyao To: Thomas Sobczynski , "gcc-help@gcc.gnu.org" Date: Tue, 11 Jan 2022 01:16:04 +0800 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3037.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, JMQ_SPF_NEUTRAL, KAM_SHORT, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org 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: Mon, 10 Jan 2022 17:16:10 -0000 On Mon, 2022-01-10 at 16:47 +0000, Thomas Sobczynski via Gcc-help wrote: > I would appreciate insight on a compilation error while building GCC > 11 to run on Windows, targeting bare metal ARM, from a GNU/Linux build > environment (specifically Ubuntu via WSL2). > > I have a current (within a few days) clone of the Git repo at the HEAD > of releases/gcc-11. > > > *** Source tree: > $ git status > On branch releases/gcc-11 > Your branch is up to date with 'origin/releases/gcc-11'. > > > *** Build environment: > $ gcc -v > Using built-in specs. > COLLECT_GCC=gcc > COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper > OFFLOAD_TARGET_NAMES=nvptx-none:hsa > OFFLOAD_TARGET_DEFAULT=1 > Target: x86_64-linux-gnu > Configured with: ../src/configure -v --with-pkgversion='Ubuntu 9.3.0- > 17ubuntu1~20.04' --with-bugurl=file:///usr/share/doc/gcc- > 9/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj- > c++,gm2 --prefix=/usr --with-gcc-major-version-only --program-suffix=- > 9 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker- > build-id --libexecdir=/usr/lib --without-included-gettext --enable- > threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu -- > enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default- > libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify - > -enable-plugin --enable-default-pie --with-system-zlib --with-target- > system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable- > werror --with-arch-32=i686 --with-abi=m64 --with-multilib- > list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable- > offload-targets=nvptx-none=/build/gcc-9-HskZEa/gcc-9-9.3.0/debian/tmp- > nvptx/usr,hsa --without-cuda-driver --enable-checking=release -- > build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux- > gnu > Thread model: posix > gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04) > > > For better or worse, I'm using GNU Make to drive the build process > from the next level up from the GCC source tree, i.e. my Make is > calling $(MAKE) to invoke the GCC build. Extracting the recipe steps, > here is how I'm attempting to build GCC: > > Recipe steps: > > # Obtain GCC source for the release branch of interest. > # > # "If you do not intend to make changes to the source, you can avoid > installing these build tools by running contrib/gcc_update." > # https://gcc.gnu.org/git.html > > git clone --branch releases/gcc-11 --depth 1 > git://gcc.gnu.org/git/gcc.git $(COMPILER_ROOT)/gcc > cd $(COMPILER_ROOT)/gcc && contrib/gcc_update > > # "If you also intend to build binutils (either to upgrade an existing > installation or for use in place of the corresponding tools of your > OS), unpack the binutils distribution ... in the same directory..." > # https://gcc.gnu.org/install/download.html > # https://www.gnu.org/software/binutils/ > > git clone --branch binutils-2_37 --depth 1 > git://sourceware.org/git/binutils-gdb.git > $(COMPILER_ROOT)/gcc/binutils > > # "Likewise the GMP, MPFR and MPC libraries can be automatically built > together with GCC. You may simply run the > contrib/download_prerequisites script in the GCC source directory to > set up everything." > > cd $(COMPILER_ROOT)/gcc && contrib/download_prerequisites > > # Configuration > # https://gcc.gnu.org/install/configure.html > # > # "The build machine is the system which you are using, the host > machine is the system where you want to run the resulting compiler > (normally the build machine), and the target machine is the system for > which you want the compiler to generate code." > # We're going to use WSL + Ubuntu + GCC to build a toolchain to run on > Windows targeting ARM. > > cd $(COMPILER_ROOT)/build && $(COMPILER_ROOT)/gcc/configure -- > host=x86_64-w64-mingw32 --target=arm-none-eabi -- > prefix=${TOOLCHAIN_ROOT} --enable-vtable-verify --with-multilib- > list=aprofile,rmprofile --enable-target-optspace --enable- > languages=c,c++,lto --enable-large-address-aware > > # Build the cross-compiler > # https://gcc.gnu.org/install/build.html > > $(MAKE) -C $(COMPILER_ROOT)/build > > > > I have made one change to a config script to get as far as I have: > > > $ git diff -- config/mh-mingw > diff --git a/config/mh-mingw b/config/mh-mingw > index e91367a71..a25d9dfd0 100644 > --- a/config/mh-mingw > +++ b/config/mh-mingw > @@ -11,5 +11,5 @@ STAGE4_CXXFLAGS += -D__USE_MINGW_ACCESS > >  # Increase stack limit to a figure based on the Linux default, with > 4MB added >  # as GCC turns out to need that much more to pass all the limits-* > tests. > -LDFLAGS += -Wl,--stack,12582912 > -BOOT_LDFLAGS += -Wl,--stack,12582912 > +#LDFLAGS += -Wl,--stack,12582912 > +#BOOT_LDFLAGS += -Wl,--stack,12582912 > > > I commented out those flags because they are not recognized by GCC 9 > on Linux as the toolchain building the compiler. I think these flags > are only needed for a compiler that is actually running on Windows, > which I am NOT doing; I am building a compiler FOR Windows. The option is needed for a GCC build which *will run* on Windows. On Windows the stack size is hardcoded in the PE executable, so it's needed to use -Wl,--stack to set a larger stack size. On UNIX-like it's determined run-time (with RLIMIT_STACK). '-Wl,--stack,12582912' just passes '--stack 12582912' to the linker, and the GNU linker targeting PE platforms supports it. If your "x86_64-w64- mingw32-gcc" does not recognize '-Wl,--stack,12582912', it's broken. You may remove '-Wl,--stack,12582912' and get a compiler which seems to work (i. e. it can compile a "Hello world" program), but it will then crash building a complex source code file. /* snip */ > Granting that I am proceeding from a position of ignorance, I am not > expecting an attempted invocation of "arm-none-eabi-gcc". My reasoning > is that the build process is taking place on GNU/Linux, while "arm- > none-eabi-gcc" is the name I expect for one of the compiler > executables that will run on Windows. You need to install arm-none-eabi-gcc on Linux, because otherwise you won't be able to build libgcc for arm-none-eabi (note that "arm-none- eabi-gcc.exe", which is just compiled, can't run on Linux). You may use "make all-gcc" and "make install-gcc" to skip libgcc, but a GCC build without libgcc is almost completely useless (such a build is only useful if you'll build libgcc manually later, or you are debugging GCC itself). -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University