 |
SpritesMind.Net
Sega Megadrive/Genesis development
|
| View previous topic :: View next topic |
| Author |
Message |
Chilly Willy
Very interested
Joined: 17 Aug 2007
Posts: 1960
|
 Posted: Sat Feb 26, 2011 7:01 am Post subject: Update your Genesis/32X Toolchain! |
 |
|
Building a new Genesis/32X toolchain
1 - Go here and download the following:
gcc-core-4.5.2.tar.bz2
gcc-g++-4.5.2.tar.bz2
gcc-objc-4.5.2.tar.bz2
Decompress them all in the same folder; you should end up with one folder called gcc-4.5.2.
2.1 - Go here and download mpfr-2.4.2.tar.bz2.
2.2 - Go here and download mpc-0.8.2.tar.gz.
2.3 - Go here and download gmp-5.0.1.tar.bz2.
Decompress them all in the same folder. You should have three folders called mpfr-2.4.2, mpc-0.8.2, and gmp-5.0.1. Rename them to get rid of the version numbers, leaving you with mpfr, mpc, and gmp. Copy them into the gcc-4.5.2 folder.
3 - Go here and download binutils-2.21.tar.bz2.
Decompress it in the same folder as the gcc folder so that you have two folders - gcc-4.5.2 and binutils-2.21.
4 - Go here and download newlib-1.19.0.tar.gz.
Decompress it in the same folder as gcc and binutils, leaving you with three folders - gcc-4.5.2, binutils-2.21, and newlib-1.19.0.
5 - Download this archive containing a makefile and several linker scripts.
Decompress it to the same folder as the others above.
6 - If you wish to leave the makefile with the default path of /opt/toolchains/gen, make sure you have permission to write to /opt or the toolchain will fail to install to the path. Since there's nothing critical in /opt, it's easiest just to do "sudo chmod 777 -R /opt" which allows anyone to do anything they want in /opt.
7 - Run "make -f makefile-gen" - depending on the speed of your computer, you should now have two toolchains in /opt/toolchains/gen: m68k-elf and sh-elf. Make another folder in /opt/toolchains/gen called ldscripts and copy the linker scripts from the archive into that folder.
You now have the latest gcc, binutils, and newlib for both the 68000 and the SH2. The compilers include C, C++, Objective-C, and Objective-C++ for both the 68000 and the SH2.
8 - Make a bin folder in /opt/toolchains/gen. Copy whatever misc tools you use into it, like sixpack or bin2c.
9 - You'll need the proper exports to use the toolchains, and assuming you left the path to /opt, they would be:
For the 68000:
export GENDEV=/opt/toolchains/gen
export PATH=$GENDEV/m68k-elf/bin:$GENDEV/bin:$PATH
For the 32X:
export GENDEV=/opt/toolchains/gen
export PATH=$GENDEV/sh-elf/bin:$GENDEV/m68k-elf/bin:$GENDEV/bin:$PATH
Here is an archive with example code - it includes Tic-Tac-Toe in both C and C++ for both the MD and the 32X, as well as my 32X version of Yeti3D with Module playing and sound effects. Also included are the latest linker scripts to be copied to /opt/toolchains/gen/ldscripts/.
MD_32X_Examples.7z
Last edited by Chilly Willy on Thu Mar 24, 2011 11:28 pm; edited 4 times in total |
|
| Back to top |
|
 |
antime
Interested
Joined: 06 Feb 2011
Posts: 22
|
| Posted: Sat Feb 26, 2011 7:48 pm Post subject: |
|
|
I've built GCC 4.5.1 for m68k, and I don't recall having to do anything special to get C++ support working. I had to apply a patch so MPFR 3.0.0 would build, but that has apparently been fixed in 4.5.2. The configure command I used was just | Code: | | $ ../../gcc-4.5.1/configure --prefix=/Users/anders/local --target=m68k-elf --disable-nls --enable-languages=c,c++ --with-newlib |
In any case, it is worth pointing out that at least in my admittedly meager experience, GCC 4.5.1 produced much worse code than version 4.4.0 I used previously. |
|
| Back to top |
|
|
sega16
Very interested
Joined: 29 Jan 2011
Posts: 191
Location: U.S.A.
|
| Posted: Sun Mar 06, 2011 4:20 pm Post subject: |
|
|
Edit:To get makefiles on windows go to :http://gnuwin32.sourceforge.net/packages/make.htm
And edit your path once you install it.
So i tried to build the make files and got "make is not recognized as an internal or external command" (yes I am using windows 7)is there a package I need to download for make?
it appears there is a version 3 of mpfr available is your link just old? or the old version better.I am just gonna try v.3
Edit and also mpc is on .9
Last edited by sega16 on Sun Mar 06, 2011 5:22 pm; edited 1 time in total |
|
| Back to top |
|
|
powerofrecall
Very interested
Joined: 17 Apr 2009
Posts: 82
Location: USA
|
| Posted: Sun Mar 06, 2011 5:21 pm Post subject: |
|
|
The instructions he posted are for linux/unix type machines. They won't work on windows without an environment like cygwin or msys. I'm taking a shot at building it under msys + mingw32 and it looks like it's doing fine so far. If there is any interest (and it continues to build properly!) I can upload the binaries somewhere when it's done.
_________________
my album - last thursday died last week |
|
| Back to top |
|
|
sega16
Very interested
Joined: 29 Jan 2011
Posts: 191
Location: U.S.A.
|
| Posted: Sun Mar 06, 2011 5:32 pm Post subject: |
|
|
I guess so...
 |
|
| Back to top |
|
|
Chilly Willy
Very interested
Joined: 17 Aug 2007
Posts: 1960
|
| Posted: Sun Mar 06, 2011 8:15 pm Post subject: |
|
|
| antime wrote: | | I've built GCC 4.5.1 for m68k, and I don't recall having to do anything special to get C++ support working. |
Maybe it's the difference between using gcc-core + g++ instead of gcc + g++; gcc-core has problems even building with the ARM processor, so maybe it also has problems with the 68000 as well. If you want to try geting c++ for the 68000 as well, you might try that - substitute gcc-4.5.2 for gcc-core-4.5.2 and add the second pass to the 68000 target like the SH2 target.
| Quote: | | In any case, it is worth pointing out that at least in my admittedly meager experience, GCC 4.5.1 produced much worse code than version 4.4.0 I used previously. |
Usually, new versions introduce something "new" or "big", so the tenths are usually decent releases. The first update then usually breaks a bunch of stuff on the new release, so 4.x.1 releases usually suck. Then they fix it all for the next release, so 4.x.2 are pretty good. 
For Windows people - my toolchain build is based on the Dreamcast toolchain build... which is for Windows. So check out that tutorial for differences in using Windows instead of linux.
http://dcemulation.org/phpBB/viewtopic.php?f=29&t=100843 |
|
| Back to top |
|
|
powerofrecall
Very interested
Joined: 17 Apr 2009
Posts: 82
Location: USA
|
| Posted: Sun Mar 06, 2011 10:18 pm Post subject: |
|
|
I don't think I'll be uploading the binaries I got because they're about 800mb uncompressed.
On the positive side it builds Chilly's 32x mod player just fine and there are no compile problems that need to be sorted, so if you want to do this on windows, install minGW + msys, start up the msys shell, and just follow the instructions.
_________________
my album - last thursday died last week |
|
| Back to top |
|
|
Chilly Willy
Very interested
Joined: 17 Aug 2007
Posts: 1960
|
| Posted: Sun Mar 06, 2011 11:53 pm Post subject: |
|
|
| powerofrecall wrote: | | I don't think I'll be uploading the binaries I got because they're about 800mb uncompressed. |
Yeah, that's exactly why I posted the instructions and a couple files rather than make an archive. It's just too damn big! 
| Quote: | | On the positive side it builds Chilly's 32x mod player just fine and there are no compile problems that need to be sorted, so if you want to do this on windows, install minGW + msys, start up the msys shell, and just follow the instructions. |
That's good. If you can compile that, you can do anything for the MD/32X. I don't just want to do 32X stuff, I want to help others who want to do 32X stuff as well. The more folks working on the 32X, the more valuable it is for everyone. |
|
| Back to top |
|
|
antime
Interested
Joined: 06 Feb 2011
Posts: 22
|
| Posted: Mon Mar 07, 2011 1:23 am Post subject: |
|
|
| Chilly Willy wrote: | | Maybe it's the difference between using gcc-core + g++ instead of gcc + g++; gcc-core has problems even building with the ARM processor, so maybe it also has problems with the 68000 as well. |
Nah, I've been using the gcc-core and gcc-g++ packages for quite some time now. Just to test, I built 4.5.2 for the m68k-elf, sh-elf and arm-eabi targets and all built without issues. Since I had previous versions of the toolchains installed I didn't perform a two-stage bootstrap, but I suspect your problems stem from some of the configuration options in your script. I know that in the past I've had to use some some specific options to get GCC to build for more "obscure" targets like SH, but with newer versions the situation has reversed so that you can't pass some of those options if you want the build to succeed. I do know that for the targets listed above you don't need any special options for a basic C/C++ toolchain.
| Quote: | | Usually, new versions introduce something "new" or "big", so the tenths are usually decent releases. The first update then usually breaks a bunch of stuff on the new release, so 4.x.1 releases usually suck. Then they fix it all for the next release, so 4.x.2 are pretty good. |
Well, I filed a bug, but so far no-one's been interested. Since m68k is such a marginal target nowadays I kinda doubt anyone will take an active interest. There's basically one GCC developer who's still interested in it, so unless there's a universal change that happens to fix it I fear it'll only get worse as time goes on. |
|
| Back to top |
|
|
Chilly Willy
Very interested
Joined: 17 Aug 2007
Posts: 1960
|
| Posted: Mon Mar 07, 2011 2:26 am Post subject: |
|
|
| antime wrote: | | Chilly Willy wrote: | | Maybe it's the difference between using gcc-core + g++ instead of gcc + g++; gcc-core has problems even building with the ARM processor, so maybe it also has problems with the 68000 as well. |
Nah, I've been using the gcc-core and gcc-g++ packages for quite some time now. Just to test, I built 4.5.2 for the m68k-elf, sh-elf and arm-eabi targets and all built without issues. Since I had previous versions of the toolchains installed I didn't perform a two-stage bootstrap, but I suspect your problems stem from some of the configuration options in your script. |
The two-stage build is so that newlib is used when building the standard c/c++ libs. You build binutils first, build the plain C compiler with no libs, use that to build the newlibs, then use BOTH of those to build the FULL gcc suite of compilers.
| Quote: | | I know that in the past I've had to use some some specific options to get GCC to build for more "obscure" targets like SH, but with newer versions the situation has reversed so that you can't pass some of those options if you want the build to succeed. I do know that for the targets listed above you don't need any special options for a basic C/C++ toolchain. |
It probably is one of the options, as you mention. There's so many of the stupid things now with no explanation of what they are for and what systems need them. 
At least the SH2 went through with all the compilers - I see more folks using C++ on the 32X than on the MD. It has the memory for it. |
|
| Back to top |
|
|
sega16
Very interested
Joined: 29 Jan 2011
Posts: 191
Location: U.S.A.
|
| Posted: Mon Mar 07, 2011 3:15 am Post subject: |
|
|
| so... How would one get this to work on windows... I read all the post but did not relay see anything that was that helpful. |
|
| Back to top |
|
|
antime
Interested
Joined: 06 Feb 2011
Posts: 22
|
| Posted: Mon Mar 07, 2011 4:51 am Post subject: |
|
|
| Chilly Willy wrote: | | The two-stage build is so that newlib is used when building the standard c/c++ libs. You build binutils first, build the plain C compiler with no libs, use that to build the newlibs, then use BOTH of those to build the FULL gcc suite of compilers. |
GCC only really needs the headers from newlib when building the compiler itself, but the newlib build process needs the compiler to generate the configuration needed by a particular target. If you know there's been no radical change that would break C compatibility (which is very unlikely) you can build the second stage directly using an existing newlib. You can then of course rebuild newlib to take advantage of any compiler improvements.
| Quote: | | At least the SH2 went through with all the compilers - I see more folks using C++ on the 32X than on the MD. It has the memory for it. |
Well, C++ by itself doesn't really cost anything, and if you take advantage of the idioms offered by the language it usually costs less than if you were to implement them yourself. And if you think C++ is expensive, Objective-C is orders of magnitude above that.
| sega16 wrote: | | so... How would one get this to work on windows... |
Cygwin is by far the easiest way to build GCC under Windows. It should work pretty much out-of-the-box. |
|
| Back to top |
|
|
Chilly Willy
Very interested
Joined: 17 Aug 2007
Posts: 1960
|
| Posted: Mon Mar 07, 2011 6:05 am Post subject: |
|
|
| antime wrote: | | Chilly Willy wrote: | | The two-stage build is so that newlib is used when building the standard c/c++ libs. You build binutils first, build the plain C compiler with no libs, use that to build the newlibs, then use BOTH of those to build the FULL gcc suite of compilers. |
GCC only really needs the headers from newlib when building the compiler itself, but the newlib build process needs the compiler to generate the configuration needed by a particular target. If you know there's been no radical change that would break C compatibility (which is very unlikely) you can build the second stage directly using an existing newlib. You can then of course rebuild newlib to take advantage of any compiler improvements. |
But if you're building a clean toolchain for cross-compiling, you almost certainly don't have the needed newlib. That's the point - you probably only have the "native" newlib for your system, which will NOT make a proper build.
| Quote: | | Quote: | | At least the SH2 went through with all the compilers - I see more folks using C++ on the 32X than on the MD. It has the memory for it. |
Well, C++ by itself doesn't really cost anything, and if you take advantage of the idioms offered by the language it usually costs less than if you were to implement them yourself. And if you think C++ is expensive, Objective-C is orders of magnitude above that. |
The obj-c stdlib is TINY compared to the c++ stdlib. Granted you won't be using EVERYTHING in the lib, but it's well known that C++ has ridiculous requirements for the libs. However, much of that can go in rom, so I suppose it's POSSIBLE to do some stuff on the MD in C++, I just don't see it.
| Quote: | | sega16 wrote: | | so... How would one get this to work on windows... |
Cygwin is by far the easiest way to build GCC under Windows. It should work pretty much out-of-the-box. |
Install CygWin and go into the cygwin terminal, not the Windows command shell. Then follow the linux directions. I think that's what he's saying.
 |
|
| Back to top |
|
|
antime
Interested
Joined: 06 Feb 2011
Posts: 22
|
| Posted: Mon Mar 07, 2011 6:30 am Post subject: |
|
|
| Chilly Willy wrote: | | But if you're building a clean toolchain for cross-compiling, you almost certainly don't have the needed newlib. That's the point - you probably only have the "native" newlib for your system, which will NOT make a proper build. |
Of course. But after you've done it once, there's usually no need to spend the extra time for a full bootstrap.
| Quote: | | The obj-c stdlib is TINY compared to the c++ stdlib. Granted you won't be using EVERYTHING in the lib, but it's well known that C++ has ridiculous requirements for the libs. |
I guess you mean the Objective-C runtime, you also need a class library to actually do anything. But keep in mind that Objective-C is a dynamic language; whereas C++ method calls are function calls going through at most one level of indirection, the corresponding Objective-C mechanism works by sending a signature to the runtime which uses it to look up the function for the recipient class. The dynamic nature of the language also means it's more or less impossible for the linker to know which parts of a library is actually needed, so you're pretty much forced to include the whole thing. |
|
| Back to top |
|
|
powerofrecall
Very interested
Joined: 17 Apr 2009
Posts: 82
Location: USA
|
| Posted: Mon Mar 07, 2011 4:18 pm Post subject: |
|
|
Windows GCC 4.5.2 toolchain (about 55mb compressed, 800+ uncompressed)
I added Make and an environment batch file to this package and it will function at a windows command prompt, but I recommend downloading msys and setting your environment variables for the toolchain in there so you can have unix commands in your makefiles.
Tested with chilly's 32x mod player and my own in-progress MD project, seems to work fine.
_________________
my album - last thursday died last week |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
