Page 1 of 1
Toolchain Issues - GCC 9.2.1 & Binutils 2.33.1
Posted: Tue Dec 03, 2019 3:18 am
by ThisMayWork
Hello everyone,
I tried to upgrade my toolchain to use GCC 9.2.1 & Binutils 2.33.1 (mainly due to GCC requiring autoconf 2.64 to build, which the distro I use upgraded to 2.69), and although the executables build as expected, compiling anything with the toolchain yields the following:
Code: Select all
/tmp/cc6Hmkvc.s: Assembler messages:
/tmp/cc6Hmkvc.s:26: Error: invalid instruction suffix for `push'
.
.
.
/tmp/cc6Hmkvc.s:200: Error: invalid instruction suffix for `push'
If I understand the error message correctly, I have 32bit capable Binutils but GCC is producing 64bit assemblies, which of course is not going to work. However, my GCC compilation method is the same I was using for 8.3.0, which worked as expected.
Did something major change in 9.x, enough to break the build process?
I am not exactly sure what I am missing here. Any help appreciated.
Thank you in advance,
Nick
Re: Toolchain Issues - GCC 9.2.1 & Binutils 2.33.1
Posted: Tue Dec 03, 2019 4:33 am
by iansjack
What command are you using to compile 32-bit code?
Re: Toolchain Issues - GCC 9.2.1 & Binutils 2.33.1
Posted: Tue Dec 03, 2019 5:27 am
by ThisMayWork
iansjack wrote:What command are you using to compile 32-bit code?
Here are the relevant parts of my Makefile.
Code: Select all
CFLAGS=-nostdlib -nostdinc -fno-builtin -fno-stack-protector -std=c11 -I ./inc -D DEBUG -g
CC=./toolchain/bin/i686-elf-gcc
.c.o:
@$(CC) $(CFLAGS) -o $@ -c $<
Re: Toolchain Issues - GCC 9.2.1 & Binutils 2.33.1
Posted: Tue Dec 03, 2019 5:49 am
by ThisMayWork
One other thing I am suspecting is that during compilation, my cross-compiler resorts to my system install of Binutils instead of the i686-target one. How can I easily check this?
Re: Toolchain Issues - GCC 9.2.1 & Binutils 2.33.1
Posted: Tue Dec 03, 2019 6:01 am
by iansjack
My suspicion is that you are trying to assemble with the system 64- bit assembler, which would imply that you did something wrong when building the cross compiler (but I'm not sure what). Did you follow exactly the instructions in the Wiki?
I believe that specifying -v when compiling will show the commands being called. I've also read that there is a -B option to specify the location of binutils, but I've never had to use that.
Re: Toolchain Issues - GCC 9.2.1 & Binutils 2.33.1
Posted: Tue Dec 03, 2019 7:08 am
by ThisMayWork
iansjack wrote:My suspicion is that you are trying to assemble with the system 64- bit assembler, which would imply that you did something wrong when building the cross compiler (but I'm not sure what). Did you follow exactly the instructions in the Wiki?
I believe that specifying -v when compiling will show the commands being called. I've also read that there is a -B option to specify the location of binutils, but I've never had to use that.
I might have wrongly ordered the fresh-built binutils in my PATH when building the cross-gcc, causing it to pick up my system's Binutil install, which targets 64bit. The thing is, I believe I have made the same mistake in the past, but on a 32bit host system and it is quite surprising that nothing broke, causing me to think this was the correct way to do this.
I am rebuilding right now, I'll get back to the thread to post if that was the solution.
Thank you for the info, much appreciated!
Re: Toolchain Issues - GCC 9.2.1 & Binutils 2.33.1
Posted: Wed Dec 04, 2019 2:52 am
by ThisMayWork
Turns out the issue was a combination of multiple different sub-issues, one of which are very peculiar (at least to me):
- - I was building Binutils with make -k, which caused part of the build to fail, and only part of the toolchain to build.
- I was messing up the PATH, causing the GCC build process to pick up my host system Binutils install.
- I was automating the process with a build script, which I in turn called as a target of my Makefile, which somehow screwed up the process due to a Makefile using make ( 
). I would like to hear any insight on this.
Thank you for the help!
-Nick
Re: Toolchain Issues - GCC 9.2.1 & Binutils 2.33.1
Posted: Wed Dec 04, 2019 7:01 am
by Solar
I fear you'd have to be a bit more specific on that third issue. Or, in StackExchange parlance, "unclear what you're asking; please provide a minimal example".
Re: Toolchain Issues - GCC 9.2.1 & Binutils 2.33.1
Posted: Thu Dec 05, 2019 1:53 am
by ThisMayWork
Solar wrote:I fear you'd have to be a bit more specific on that third issue. Or, in StackExchange parlance, "unclear what you're asking; please provide a minimal example".
So what used to happen is that I had a "toolchain" target in my Makefile, which was supposed to build the toolchain. It was literally just
. Now comes the weird part, while running the script itself in a terminal session produces a working toolchain without any compilation issues whatsoever, running
make toolchain, which one would suppose will work, breaks the compilation of Binutils. More specifically,
configure works as expected, and during
make it errors out on being unable to find
Multilib.am (Error 127).
I can try to provide a minimal reproduction example, but I think this might be a usual issue/limitation of make which I don't know of.
Re: Toolchain Issues - GCC 9.2.1 & Binutils 2.33.1
Posted: Mon Dec 16, 2019 8:58 am
by davidv1992
My best guess at what might be causing it would be that it has something to do with Gnu make's recursive make support. It might be that somehow the outermost makefile of one of the built components is detecting that it is already being recursively called, and changes its behaviour in such a way that it fails in the way you describe.
Re: Toolchain Issues - GCC 9.2.1 & Binutils 2.33.1
Posted: Mon Dec 16, 2019 4:42 pm
by klange
CC=./toolchain/bin/i686-elf-gcc
This suggests to me that your toolchain is not in your $PATH and thus gcc is unable to find an equivalent "i686-elf-as" and friends and is falling back to just "as".
Re: Toolchain Issues - GCC 9.2.1 & Binutils 2.33.1
Posted: Tue Dec 17, 2019 1:00 am
by Korona
Note that the bug that klange is mentioning can be fixed by adding links like we do here:
click me.