• Rise from your gwave!

Building your own toolchains

Discussion in 'Saturn Dev' started by antime, Dec 25, 2007.

  1. slinga

    slinga Member

    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...
     
  2. ExCyber

    ExCyber Staff Member

    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.
     
  3. mirakus

    mirakus New Member

    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?
     
  4. Chilly Willy

    Chilly Willy New Member

    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/
     
  5. mirakus

    mirakus New Member

    Thanks! I'll definitely go ahead and give it a shot, as I'm desperate to get something working at this point!
     
  6. mirakus

    mirakus New Member

    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!
     
  7. ExCyber

    ExCyber Staff Member

    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.
     
  8. Chilly Willy

    Chilly Willy New Member

    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! [​IMG]
     
  9. antime

    antime Extra Hard Mid Boss

    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.
     

Share This Page