02/20/2003: It has been possible to build the DevKit on Windows XP for a while now, so I removed the warning not to use it.
10/30/2001: What is the cause of the error message "conflicting versions of cygwin1.dll detected. Use only the most recent version."
10/21/2001: I get "undefined reference to cos" when compiling programs that use functions from math.h
10/21/2001: How do I compile C++ programs?
08/24/2001: I'm tired of setting the path all the time, what do I do to make this stick?
08/24/2001: I was mistaken about having to put the DevKit exactly where I say, you can install it anywhere you want.
08/20/2001: Changed specification of GCC_EXEC_PREFIX to use cygdrive convention in order to fix a bug.
08/17/2001: Added that you need around 400MB free to rebuild from source
08/16/2001: Do I have to have Cygwin installed?
08/16/2001: How do I use this from the Cygwin environment?
What to I do to get this working?
Decide which packages you need, download and unzip them. The most popular program for unzipping zip files seems to be WinZip (www.winzip.com)
If you are using the windows command prompt, then after getting everything unpacked you will need to put the bin directory into your path like this:
PATH=c:\devkitadv\bin;%PATH%Substitute where you actually unzipped the files for "c:\devkitadv\"
If you run gcc at this point you should see "no input files". At this point you should be ready to compile a program.
I'm tired of setting the path all the time, what do I do to make this stick?
If you want a quick way to bring up a command window then make a batch or command file. You can double-click on them to bring up a window that's ready to go. They should look like this:
-- devkit.bat --
@echo off PATH=c:\devkitadv\bin;%PATH% command--
If you are using Windows NT/2000, then its better to use a .cmd file:
-- devkit.cmd --
@echo off PATH=c:\devkitadv\bin;%PATH% cmd--
Put any other variables you may want to set in there as well. You could even put in a "cd c:\myproject\" if you are extra lazy.
I set the path correctly, but I'm getting the "installation problem" error!
Sometimes you have to set an extra variable to get things to work.
GCC_EXEC_PREFIX=/cygdrive/c/devkitadv/lib/lib-gcc/The forward slashes and trailing slash are very important. If you installed in a different location then change /cygdrive/c/devkitadv/ to where you installed the DevKit. The "cygdrive" part is a funky workaround that Cygnus used for MS-DOS drive letters. Just replace the c with the letter of the drive.
Do I have to have Cygwin installed?
No. Although the DevKit currently requires the Cygwin DLL files, it comes with them. I am considering using MinGW, but the only difference you would probably notice is a slightly smaller download size.
How do I use this in the Cygwin environment?
The commands should look something like this:
PATH=/path/to/devkitadv/bin:$PATH GCC_EXEC_PREFIX=/path/to/devkitadv/lib/gcc-lib/If you have installed the DevKit somewhere other than under your Cygwin directory, you can still use it from within Cygwin. Just use the Cygwin method of accessing drive letters.
I get "undefined reference to cos" when compiling programs that use functions from math.h
The math functions are not in the standard library which gcc automatically links with, so you have to tell it to link with the math library. To do this add the option -lm to the command line that you use to link everything together (should be the same one that has the -o mygame.elf option). This will tell gcc to use libm.a when it links.
How do I compile C++ programs?
There are two ways. One is to use the program g++ instead of gcc when you compile. g++ is the same as gcc except that it sends options to the sub programs that actually do the work which work with C++. The other way is to add the option -lstdc++ to the command line. This tells gcc to link with the standard C++ library. I prefer using g++ because it knows more about properly compiling for C++ than I do.
How do I build this myself?
I'll go into more detail later on this, but the gist of it is:
Does the DevKit support both Thumb and ARM instruction sets?
Yes, it will do both. Use the options -mthumb and -marm to tell the compiler which you want. It does ARM by default.
It can even properly link programs that use both, which is called "interworking." Use -mthumb-interwork on all your modules if you mix both in your program or you will get annoying warnings from the linker.
In binutils 2.11.2 which the DevKit uses, the warning says "module X does not support interworking while module Y does not." Which makes no sense to warn about because it should only complain if there is a mismatch.
It turns out this is a minor bug which causes the last phrase to say the opposite of what it means. This has been patched for the next version of binutils, but I'll apply the patch to the next release of the DevKit whether binutils 2.11.3 is out or not.
Are there any additional options I might want to specify for the cpu?
You can specify -mcpu=arm7tdmi so that the compiler and assembler know what exactly what type of chip it is targeting. This helps to report unsupported opcodes as well as use any instructions that the arm7tdmi may have that other ARM chips do not.
The compiler was configured with --with-cpu=arm7tdmi, so this option may be redundant.
Also, -mtune=arm7tdmi, may activate cpu model specific optimizations. I do not know if any such optimizations exist, but it can not hurt to add this option in case someone contributes some to gcc in the future.
Why are there four versions of the standard libraries in each package?
This is because of a feature of gcc called multilib. Four versions of the standard library are generated to support ARM/Thumb and interworking/non-interworking. In combination that is four libraries compiled with the different options.
|options||library sub-directory used|
|-marm (the default)||./|
This should not result in, for example, having two copies of sprintf in your code if you call sprintf from Thumb code and ARM code in the same project. Which version of the standard library you link with should be determined by your final linking command line. For example, if you want to use the thumb/interwork version of the library, your command line would look like this.
gcc -mthumb -mthumb-interwork armcode.o thumbcode.o -o game.elfAny ARM code code calling the standard library in this example will use interworking to switch to thumb mode and back.
Note: I think this is how it works, but I have not tested it.
So, if I am writing a library that I want to work with the DevKit do I have to do anything special?
Please compile your library four times with the different combinations of options and have it install into the appropriate library directory. This way everyone can use the library out of the box without warnings or worse "File not found" errors.
Do I still have to support multilib if my library is all ARM assembly? The different options have no effect on the code that is output.
Unfortunately, If it's all assembly, you still have to have object files that are marked as interwork and non-interwork to prevent interwork mismatch warnings, and copies in the Thumb and ARM directories to prevent "File not found" errors even if the code in the libraries ends up being identical.
It should be possible to write a shell script which uses objcopy to copy a library into all four places with different flags if you are concerned about zip file size.
Why when I try to compile do I get an error saying, "Virtual memory exhausted: Invalid argument" ?
Get the latest packages.
Hopefully, this bug has been fixed in the latest version. I changed the memory manager that gcc uses in order to work around a bug in one of the POSIX functions in Cygwin (mmap). Compilation might be slower on machines with lower memory because it now uses a less efficient scheme which may take more memory. This might introduce new bugs, but I have not seen anything yet.
When compiling C++ programs I get linker errors about some strange symbol called LLSDA. Whats up?
A bug in gcc 3.0 which has been patched but not officially released yet. I applied the patch and downloading the latest version of the libstdcpp package should fix it.
What is the cause of the error message "conflicting versions of cygwin1.dll detected. Use only the most recent version."
It means that you have more than one copy of the cygwin1.dll file on your disk and that two different cygwin programs have found different versions. It probably would not be a problem if both where the same version, but one is older than the other. Solve the problem by updating your cygwin distribution if you have it installed and/or by finding all copies of cygwin1.dll on your harddrive and replacing them with the more recent version.
You may also consider using the "cygcheck" utility included with Cygwin if you have that installed. I'm not going to tell you how to use it however.
To check the version, right click on the dll file, choose properties, then choose the version tab.