Building your own toolchains

Excellent that worked. It compiled and I was able to test with Yabause.

One thing I don't understand though: I was able to compile and test some SGL samples using "sh-elf-*" without using objcopy on the libraries. Is GCC smart enough to automatically convert coff libs to elf? I'm can't explain why it worked...
 
slinga said:
Excellent that worked. It compiled and I was able to test with Yabause.

One thing I don't understand though: I was able to compile and test some SGL samples using "sh-elf-*" without using objcopy on the libraries. Is GCC smart enough to automatically convert coff libs to elf? I'm can't explain why it worked...
If memory serves, ld (or rather libbfd) has been smart enough to link COFF and ELF objects into a single output binary for some years now.
 
Sorry to resurrect an old thread here, but I'm having some problems. I've followed your instructions to a T, with the exception that I'm not using a separate build directory for each portion of the toolchain.

I've gotten to the stage where I'm building the final version of gcc, and I'm getting this error: make[2]: *** No rule to make target `../.././gcc/libgcc.mvars'. Stop.

I'm using my system's install of gcc 4.4.3 to build and trying to install (as my cross compiler) gcc 4.5.3. I have been able to successfully build an x86 version of gcc 4.5.3 using my 4.4.3. Trying to build the toolchain with 4.5.3 (which I have done), gives me the same error.

Any ideas on what this is and how to fix it?
 
Try following my guide for making a toolchain for the 32X - it should be fine for the Saturn as well as it builds a plain SH2 toolchain with libraries along with a plain 68000 toolchain with libraries. It builds gcc 4.5.2 with C, C++, Obj-C, and Obj-C++ compilers for both SH2 and 68000, as well as all associated gcc libs. It also build newlib for both processors giving you libc and libm.

http://segaxtreme.net/community/topic/17455-building-your-own-md32x-toolchain/
 
Chilly Willy said:
Try following my guide for making a toolchain for the 32X - it should be fine for the Saturn as well as it builds a plain SH2 toolchain with libraries along with a plain 68000 toolchain with libraries. It builds gcc 4.5.2 with C, C++, Obj-C, and Obj-C++ compilers for both SH2 and 68000, as well as all associated gcc libs. It also build newlib for both processors giving you libc and libm.

Thanks! I'll definitely go ahead and give it a shot, as I'm desperate to get something working at this point!
 
Found my problem! I had considered doing all of this separate build directories optional, but it looks like that was my problem. Once I decided to build every component in its own build dir, everything worked!
 
An all-in-one build can be done, but it must be set up in a particular way and isn't really the "supported" method. I think it exists mostly for toolchain developers who routinely need to debug interactions among gcc/binutils/libc.
 
It's easier and cleaner to have each thing build on its own. I can't imagine trying to build a 32X/Saturn toolchain all in one build directory... it boggle the mind!
smile.gif
 
Updated instructions for building current versions:

1. Build and install binutils as described above.
2. Download and extract the GCC source archive.
3. Enter the GCC source folder and execute the following command (requires wget):
Code:
$ ./contrib/download_prerequisites
4. Download and extract the Newlib source archive.
5. Copy (or link) the "newlib" and "libgloss" folders from the Newlib source tree into the GCC source folder.
6. Create a build folder.
7. Enter the build folder and execute the following command:
Code:
$ $PATH_TO_GCC_SOURCES/configure --prefix=$INSTALLDIR --target=$TARGET --enable-languages="c,c++" 2>&1 | tee configure-log
8. Build the whole shebang:
Code:
$ make all 2>&1 | tee make-all-log
If you have a fast multicore machine, you can build in parallel. If you run into problems, try reducing the number of parallel processes (-jN):
Code:
$ nice -n 20 make -j all 2>&1 | tee make-all-log
9. If all goes well, install your brand-spanking new compiler:
Code:
$ make install 2>&1 | tee make-install-log

Doing a single stage build can save a lot of time, and building the dependent libraries in-tree avoids breaking your existing compiler if eg. a later GCC updates the version requirements.
 
Back
Top