Talk:GCC Cross-Compiler: Difference between revisions

Content deleted Content added
m Bot: Replace deprecated source tag with syntaxhighlight
 
(12 intermediate revisions by 4 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.
<sourcesyntaxhighlight lang="bash">export PREFIX=/usr/local/cross
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</sourcesyntaxhighlight>
 
Source file (reduction.c):
<sourcesyntaxhighlight lang="c">void _start()
{
}</sourcesyntaxhighlight>
 
Built using:
<sourcesyntaxhighlight lang="bash">i386-elf-gcc -ffreestanding -c reduction.c</sourcesyntaxhighlight>
 
Diagnostics:
Line 121 ⟶ 138:
 
Preprocessed source:
<sourcesyntaxhighlight lang="c"># 1 "reduction.c"
# 1 "<built-in>"
# 1 "<command-line>"
Line 127 ⟶ 144:
void _start()
{
}</sourcesyntaxhighlight>
 
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):
<sourcesyntaxhighlight lang="bash">export CC=/usr/bin/gcc-4.2
export CXX=/usr/bin/g++-4.2
export CPP=/usr/bin/cpp-4.2
export LD=/usr/bin/gcc-4.2</sourcesyntaxhighlight>
 
And repeated the rest of the process as-is. Doing so creates a functional toolchain.
Line 152 ⟶ 169:
== 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.
Return to "GCC Cross-Compiler" page.