Talk:GCC Cross-Compiler: Difference between revisions
Content deleted Content added
Re: Texinfo |
m Bot: Replace deprecated source tag with syntaxhighlight |
||
| (45 intermediate revisions by 15 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==
I've just added another working config and the table of "known good" configurations is now getting a little big when viewed on a 1024x768 4:3 monitor. The situation is only going to get worse, so could I make some suggestions:
# Remove GCC versions < 4.0.0 ''and/or''
# Make the table reverse-chronological, so GCC 4.5.0 / Binutils 2.20 would be at the top left and version numbers would decrease rightwards and downwards, so no horizontal scroling for the latest version. ''and/or''
# Something else... ''and/or''
# Club together and buy me a nice widescreen monitor ;o)
Any thoughts, before I make such a big change? I favour option 2 (or 4!) so that all information is left intact --[[User:Aj|Aj]] 12:29, 11 February 2010 (UTC)
: I support this, there should be a minimal resolution that all the articles should target.. most of my monitors are <= 1024x768, so that's my biased recommendation. --[[User:Brynet-inc|Brynet-Inc]] 03:00, 13 February 2010 (UTC)
: I would go with option 1, since GCC4 is (AFAIK) fairly standard and mature now. If we go with option 1 however, I would also suggest dumping the other information regarding GCC3 from the article. Option 2 is an idea, but it won't decrease the size of the table and it's getting a bit big IMHO. --[[User:Creature|Creature]] 11:46, 13 February 2010 (UTC)
: I don't agree with option 1, there still may be people using that version of the compiler. --[[User:Brynet-inc|Brynet-Inc]] 20:42, 13 February 2010 (UTC)
: What if we were to split the table into two tables: one for GCC3 and one for GCC4? That would fix the exaggerated width and make it a little less overwhelming. --[[User:Creature|Creature]] 11:18, 14 February 2010 (UTC)
: I have copied the table section to [[User:AJ/GCC_Cross-Compiler]] so that I can play around with the layouts. I won't do anything to the main article yet. I think this is such a well-used article that I will start a topic on the forums once I have a suggested replacement. --[[User:Aj|Aj]] 09:22, 15 February 2010 (UTC)
==Building Target-libgcc==
At the end of cross-compiler creation, I always run make all-target-libgcc install-target-libgcc for long long integer support and so on. I wonder if this should be added to the Cross-Compiler tutorial, as the sensible time to do this is when you already have a configured build directory. If so, how should it be added; perhaps just as a footnote or should it actually be listed as an (optional) additional build command at the end of the GCC build? --[[User:Aj|Aj]] 10:56, 3 August 2009 (UTC)
:+1 for adding this to the tutorial. I think it would be best to keep it away from the bulk of the tutorial and leave it as a "Now you're done" sort of thing. That way people (especially those new to this kind of stuff) will be happy to leave with a cross-compiler without libgcc, and those who are interested in the additional features libgcc provides will read further. My 2c. --[[User:Pcmattman|pcmattman]] 12:02, 3 August 2009 (UTC)
: I have inserted this information before the troubleshooting section. The idea is that the libgcc targets should be built while the configured gcc directory still exists, so I hope to catch people before they close Bash and delete their temporary build-gcc directory. I have also added a link to a summary of libgcc and have deleted the (dead) link to bill gaitliff's site - he used to offer a free advice page, but now seems to provide commercial cross-compiler services under a different URL. --[[User:Aj|Aj]] 10:04, 25 August 2009 (UTC)
==Compilation of x86_64-elf Target==
I have just tried with GCC 4.3.1 and 4.3.2 and it appears that GCC no longer requires the x86_64-elf target adding manually for configuration (it now works in exactly the same way as i586-elf. I am going to make a few changes to the article to reflect this, but where does this leave the specific x86_64 Cross compiler article? Deleted? Added as a cross-reference for people building against older versions? --[[User:Aj|Aj]] 10:41, 29 September 2008 (UTC)
:I would put that information in the x86_64 crosscompiler article, rather than adding it here, since people are told to go there anyway. - [[User:Combuster|Combuster]] 10:58, 29 September 2008 (UTC)
==Cross-Reference Suggestion==
I was thinking of referencing the Porting Newlib article from Step 2 of this tutorial and/or the Articles section at the end of the page - any problems with that? --[[User:AJ|AJ]] 07:38, 1 October 2007 (CDT)
:No problem at all. - [[User:Combuster|Combuster]] 10:51, 1 October 2007 (CDT)
==Binutils requires Flex & Bison==
I'm editing the article because flex and bison are still required for at least binutils 4.2.2. [[User:CodeAnxiety|CodeAnxiety]] 01:45, 31 January 2008 (CST)
==What does it Do?==
After reading through part 1, i fail to see what is done that cannot be done by GCC before creation of this cross compiler. It seems to be a waste of time, and nothing is specified about the platform that can't be accomplished by all other versions of GCC. --[[User:Tyler|Tyler]] 22:50, 15 March 2007 (CDT)
Line 23 ⟶ 78:
::::I checked my cygwin setup, and noticed texinfo is installed without me specifically selecting it, so it either is a dependency of one of the other packages I do have, or its installed by default. Since solar's regression test of removing, reinstalling, selecting the basic install + the packages listed always results in an environment that can build the crosscompiler, I don't think its an error in the tutorial. - [[User:Combuster|Combuster]] 02:55, 14 September 2007 (CDT)
::::For those having problems building binutils without texinfo installed, run the configure step as normal. When that finishes, do this:
::::echo "MAKEINFO = :" >> Makefile
::::That command overrides the MAKEINFO variable in the Makefile, setting it to something that does not exist. This causes make to skip attempting to build (and subsequently install) the documentation. --[[User:Quok|quok]] 06:20, 26 August 2008 (UTC)
== Version Junkies... ==
Pretty impressive to see how GCC 4.5.0 is listed in the "compatibility matrix", when it has not even hit ftp.gnu.org yet... someone *is* eager to use the latest... ;-) -- [[User:Solar|Solar]] 07:52, 12 February 2010 (UTC)
* I was thinking exactly the same thing... --[[User:Creature|Creature]] 17:19, 12 February 2010 (UTC)
== GMP, MPFR and MPC ==
See [[Talk:Cross-Compiler_Successful_Builds]] and corresponding [http://forum.osdev.org/viewtopic.php?f=8&p=176033#p176033 forum thread]. These supporting libraries are general-purpose and not specific to your cross-compiling target, so it is best to install them the way your system usually installs packages, instead of compiling them from source. Which you can do properly only when you're root and remember to install to /usr/local, while no SysAdmin should have anything against installing them on a shared system you might be using.
== RE: New "Note 2" ==
Quote: "Cygwin users should use the default Windows 'terminal'. Else you may get the error message <path-to-as>/as.exe: Bad Address". Can someone explain this one to me? This tutorial works fine in the Cygwin bash shell, as well as from the Windows 'cmd' shell (if the Cygwin /bin is in your PATH). This note seems misleading and misguided. --[[User:Pcmattman|pcmattman]] 05:20, 13 December 2010 (UTC)
:I cannot picture why this should be, either. I did send the user (whose only activity on either the Wiki and the forum was this edit) a PM on the forum asking him to elaborate, and reverted his edit until he does. -- [[User:Solar|Solar]] 10:03, 13 December 2010 (UTC)
== On Mac OS X Lion ==
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.
<syntaxhighlight lang="bash">export PREFIX=/usr/local/cross
export TARGET=i386-elf
export MAKEFLAGS="-j 16"
mkdir -p ~/src/build-{binutils,gcc}/
curl ftp://ftp.gnu.org/gnu/binutils/binutils-2.22.tar.bz2 | tar -x -f - -C ~/src/
curl ftp://ftp.gnu.org/gnu/gcc/gcc-4.6.2/gcc-core-4.6.2.tar.bz2 | tar -x -f - -C ~/src/
curl ftp://ftp.gnu.org/gnu/gmp/gmp-5.0.2.tar.bz2 | tar -x -f - -C ~/src/gcc-4.6.2/
curl ftp://ftp.gnu.org/gnu/mpfr/mpfr-3.1.0.tar.bz2 | tar -x -f - -C ~/src/gcc-4.6.2/
curl http://www.multiprecision.org/mpc/download/mpc-0.9.tar.gz | tar -x -f - -C ~/src/gcc-4.6.2/
cd ~/src/build-binutils/
../binutils-2.22/configure --prefix=$PREFIX --target=$TARGET --disable-nls
make all
sudo make install
export PATH=$PATH:$PREFIX/bin
cd ~/src/build-gcc/
mv ../gcc-4.6.2/gmp-5.0.2/ ../gcc-4.6.2/gmp/
mv ../gcc-4.6.2/mpfr-3.1.0/ ../gcc-4.6.2/mpfr/
mv ../gcc-4.6.2/mpc-0.9/ ../gcc-4.6.2/mpc/
../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</syntaxhighlight>
Source file (reduction.c):
<syntaxhighlight lang="c">void _start()
{
}</syntaxhighlight>
Built using:
<syntaxhighlight lang="bash">i386-elf-gcc -ffreestanding -c reduction.c</syntaxhighlight>
Diagnostics:
<pre>reduction.c:3:1: internal compiler error: in execute_ipa_pass_list, at passes.c:1921
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.</pre>
Preprocessed source:
<syntaxhighlight lang="c"># 1 "reduction.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "reduction.c"
void _start()
{
}</syntaxhighlight>
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.
<pre>$ readlink /usr/bin/gcc /usr/bin/g++
llvm-gcc-4.2
llvm-g++-4.2</pre>
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):
<syntaxhighlight 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</syntaxhighlight>
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.
| |||