Talk:GCC Cross-Compiler: Difference between revisions
Content deleted Content added
→On Mac OS X Lion: new section |
m Bot: Replace deprecated source tag with syntaxhighlight |
||
| (20 intermediate revisions by 7 users not shown) | |||
Line 1:
== Windows Subsystem for Linux ==
Checking in for the first time in a couple of years :) Just followed the instructions for apt-get based system on WSL (Bash on Ubuntu on Windows) and it works perfectly for gcc 6.2.0 with Binutils 2.27. I'll be switching to that system over Cygwin. --[[User:Aj|Aj]] 06:23, 25 November 2016 (CST)
=== Update to WSL ===
WSL has been non-beta for a while now and I'd suggest it as the go-to method for anybody using Windows 10 now. Compatibility with builds (grub tools etc...) is now ''so'' much better than Cygwin64 and I've been using it as my main dev environment on Windows 10 since the start of the Beta. I'm happy to add the relevant notes on the main wiki page. Objections? --[[User:Aj|Aj]] 05:54, 12 January 2018 (CST)
== Repeatable Error with Cygwin 64? ==
I got a chance to have a play with my cross-compilers today (as you do...) and had a go at following the tutorial on the 64 bit version of Cygwin on Windows 8.1. Binutils version is 2.24 and GCC is 4.9.1, target is x86_64-elf. On "make install-gcc", I get the error:
<syntaxhighlight lang="bash">Verify that you have permission to grant a GFDL license for all
new text in tm.texi, then copy it to ../../gcc-4.9.0/gcc/doc/tm.texi.</syntaxhighlight>
I'm obviously not the first to get this error ([http://stackoverflow.com/questions/23839851/gcc-cross-compiler-cygwin64-gfdl-license-tm-texi reference]). This seems to be some sort of file version control issue. In my case, copying the file as suggested by the error message did ''not'' work. What ''did'' work was to re extract the tar file containing the original GCC source, overwriting the GCC source files (I assume this resets date stamps). After this, I changed back to my build-gcc folder, ran 'make install-gcc' and the process went swimmingly. I can therefore confirm that the tutorial works OK in Cygwin64 with the above proviso. I've not added this to the list of common errors in the article as I don't have time to test repeatability and would like others to confirm that this is a real issue first. (PS: Diffutils also required as the build process uses cmp at this point) --[[User:Aj|Aj]] 16:49, 25 July 2014 (CDT)
PS: It also seems like in Cygwin64, the dependency libintl-devel is also not installed by default and needs to be added to Cygwin for successful compilation, even with --disable-nls. --[[User:Aj|Aj]] 06:29, 28 July 2014 (CDT)
==Unwieldy Configurations Table Size==
Line 84 ⟶ 101:
I was building a cross-compiler (binutils 2.22, gcc 4.6.2) for i386-elf on Mac OS X 10.7.2 with Xcode 4.1 using this tutorial (from memory at first, but I double checked to make sure that I wasn't screwing things up), when I came across a rather peculiar issue. The toolchain would successfully compile and install, but when I went to use it, it would start spewing out internal compiler errors. Below are the commands I used when building the toolchain, as well as a reduction for reproducing the errors.
<
export TARGET=i386-elf
export MAKEFLAGS="-j 16"
Line 104 ⟶ 121:
../gcc-4.6.2/configure --prefix=$PREFIX --target=$TARGET --disable-nls --without-headers --with-mpfr-include=$HOME/src/gcc-4.6.2/mpfr/src/ --with-mpfr-lib=$HOME/src/build-gcc/mpfr/src/.libs/
make all-gcc
sudo make install-gcc</
Source file (reduction.c):
<
{
}</
Built using:
<
Diagnostics:
Line 121 ⟶ 138:
Preprocessed source:
<
# 1 "<built-in>"
# 1 "<command-line>"
Line 127 ⟶ 144:
void _start()
{
}</
After researching for a bit, I discovered that the issue is caused by Xcode 4.1's side-by-side installation of gcc, clang, and llvm-gcc.
Line 135 ⟶ 152:
By default, "gcc" will invoke llvm-gcc, which triggers some sort of bug in gcc's code (I didn't bother figuring out what specifically). To work around this, I set these variables at the beginning (along with PREFIX, TARGET, and MAKEFLAGS):
<
export CXX=/usr/bin/g++-4.2
export CPP=/usr/bin/cpp-4.2
export LD=/usr/bin/gcc-4.2</
And repeated the rest of the process as-is. Doing so creates a functional toolchain.
The reason I am posting this is because I suggest that these instructions be added to the tutorial, possibly in the Troubleshooting section. I'd go ahead and add it but I'm pretty new to the wiki and don't know if there's a change approval process or what. :) --[[User:Nokurn|Nokurn]] 05:47, 29 November 2011 (UTC)
:Very good description of the problem. Thank you!
:But I am confused. Your cross-compiler should reside in /usr/local/cross/bin, named i386-elf-gcc. (As your example call shows.) Whatever /usr/bin/gcc is or points to shouldn't affect it in the least. Neither should your CC / CXX / ... exports solve the problem...?!? -- [[User:Solar|Solar]] 07:11, 29 November 2011 (UTC)
::$CC & co. are used when compiling the cross-compiler. Something about using llvm-gcc to produce the cross-compiler triggers a bug of some sort in the gcc source code, so you get a defective i386-elf-gcc. At least, that's what I've come to think. I don't know how else to explain why the host compiler would affect the resulting cross-compiler. I'd dig into the gcc source code to try to figure it out but I've heard so many horror stories about that codebase that I'm breaking into a cold sweat just by entertaining the idea... --[[User:Nokurn|Nokurn]] 07:18, 29 November 2011 (UTC)
:::Ah, I see - you set those exports ''while compiling the cross-compiler'', not while using it (as I initially understood). That's definitely worth a bug report to upstream (GCC)... Funny enough, a quick Google shows that [http://llvm.org/docs/GettingStarted.html#brokengcc the animosities are mutual]. :-D I'll extend the tutorial ASAP. -- [[User:Solar|Solar]] 14:58, 29 November 2011 (UTC)
::::I'll look into putting together a bug report for them. Thanks for adding it. Great tutorial by the way. --[[User:Nokurn|Nokurn]] 22:28, 29 November 2011 (UTC)
== Multiple Versions Simultaneously ==
You can have multiple versions installed simultaneously by setting the --program-prefix and --program-suffix options during configuration. In my case I do --program-suffix=-$GCC_OR_BINUTILS_VERSION --program-prefix=$TARGET- where $GCC_OR_BINUTILS_VERSION is the version of gcc or binutils you are installing. - ChosenOreo
== ./gthr-default.h:35:10: fatal error: pthread.h: No such file or directory AND TARGET=arm-linux-gnueabihf ==
I'm building the cross-compiler to start with for the bare target as this article outlines. I ran into a problem with the "make all-target-libgcc" step with the title error: ./gthr-default.h:35:10: fatal error: pthread.h: No such file or directory, occurring at some signification point in completion. I believe I've followed the steps verbatim. and; after research, even attempted to reconfigure with --disable-threads option. There's very little additional recommendation on this error that I've found beyond, using one of the many cross-compilers somebody else has generated. I think it would be great if this talk section could have comments And after a solution is found, a section in the main page added for the corrective actions. Thanks for any feedback. If an answer appears, I'd have no problem adding a minor change to the article assuming that's permitted.
| |||