Update your Genesis/32X Toolchain!

Talk about development tools here

Moderator: BigEvilCorporation

ammianus
Very interested
Posts: 124
Joined: Sun Jan 29, 2012 2:10 pm
Location: North America
Contact:

Post by ammianus » Sun Aug 12, 2012 7:02 pm

Chilly Willy wrote: I use Geany for my IDE... Geany even has a built in terminal so I don't have to open one if I don't want to. If you are using my latest examples that set all paths in the makefile instead of using environment variables, then it's very simple to use this with any IDE - just set the build option to make the makefile... you don't have to worry about environment variables.

Code Blocks has a lot of options for things like environment variables for a project, but I find that all too much for people to deal with. That's why I like simple makefiles with all the paths set in the makefile boilerplate. People really overcomplicate makefiles these days. Just because make allows stupidly complicated makefiles is no reason to actually do so. :lol:
Yeah, I just want to call the same makefile that works for this project. One of the challenges in our case is that we have 2 toolchains in the same project, and it seems like the IDEs assume you would only use one (m68k/sh)

I'll see if I can mold code::blocks to our makefile, otherwise, try out geany, it seems to have the main features I am looking for.

Edit: no luck with c::b so far. I am trying to use geany, where do you put the environment variables from the env.bat? In your user's environment variables? Or is there a way to specify these in the Make command when we call it in geany?

Code: Select all

@Echo Off
SET GENDEV=C:\Users\Documents\roms\homebrew\_gcc\gen
SET PATH=%GENDEV%\bin;%GENDEV%\sh-elf\bin;%GENDEV%\m68k-elf\bin;%GENDEV%\UTILS;%PATH%
SET MAKE_MODE=unix
Cmd "cd" /k
[/code]

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Mon Aug 13, 2012 5:00 am

I've grown to not like environment variables... mainly because I have so many cross compilers that you simply cannot make environment variables to allow them all to work. It's simply not possible. So I put all the paths in the makefile. Then the only thing the makefile assumes the path is set for are the host tools like rm or cp. Look at a typical makefile I use now:

Code: Select all

ifdef $(GENDEV)
ROOTDIR = $(GENDEV)
else
ROOTDIR = /opt/toolchains/sega
endif

LDSCRIPTSDIR = $(ROOTDIR)/ldscripts

LIBPATH = -L$(ROOTDIR)/sh-elf/lib -L$(ROOTDIR)/sh-elf/lib/gcc/sh-elf/4.6.2 -L$(ROOTDIR)/sh-elf/sh-elf/lib
INCPATH = -I$./src -I$(ROOTDIR)/sh-elf/include -I$(ROOTDIR)/sh-elf/sh-elf/include

CCFLAGS = -m2 -mb -Ofast -Wall -g -c -fomit-frame-pointer
CCFLAGS += -DHAVE_FFBLK -DDOSISM -DWMODE=0
LDFLAGS = -T $(LDSCRIPTSDIR)/mars.ld -Wl,-Map=output.map -nostdlib
ASFLAGS = --big

PREFIX = $(ROOTDIR)/sh-elf/bin/sh-elf-
CC = $(PREFIX)gcc
AS = $(PREFIX)as
LD = $(PREFIX)ld
OBJC = $(PREFIX)objcopy

DD = dd
RM = rm -f

TARGET = Wolfenstein3D
LIBS = $(LIBPATH) -lm -lc -lgcc -lgcc-Os-4-200 -lnosys
OBJS = \
	src/crt0.o \
	src/id_ca.o \
	src/id_us.o \
	src/id_vh.o \
	src/misc.o \
	src/objs.o \
	src/vi_comm.o \
	src/vi_32x.o \
	src/wl_act1.o \
	src/wl_act2.o \
	src/wl_act3.o \
	src/wl_agent.o \
	src/wl_debug.o \
	src/sd_comm.o \
	src/sd_32x.o \
	src/adlibtables_wsw.o \
	src/wl_draw.o \
	src/wl_game.o \
	src/wl_inter.o \
	src/wl_main.o \
	src/wl_menu.o \
	src/wl_play.o \
	src/wl_state.o \
	src/wl_text.o \
	src/w3dsw_data.o \
	src/automap.o \
	src/debug_32x.o \
	src/debug_font.o

all: m68k.bin $(TARGET).bin

m68k.bin:
	make -C src-md

$(TARGET).bin: $(TARGET).elf
	$(OBJC) -O binary $< temp.bin
	$(DD) if=temp.bin of=$@ bs=2816K conv=sync

$(TARGET).elf: $(OBJS)
	$(CC) $(LDFLAGS) $(OBJS) $(LIBS) -o $(TARGET).elf

%.o: %.c
	$(CC) $(CCFLAGS) $(INCPATH) $< -o $@

%.o: %.s
	$(AS) $(ASFLAGS) $(INCPATH) $< -o $@

clean:
	make clean -C src-md
	$(RM) src/*.o src/*.bin *.bin *.elf output.map
The first few lines allow for one environment variable, and sets the main path to a default if it's not found (and it won't be on my system). Everything else for the cross compiler has a path based on that and the project spelled out in the makefile with no reliance on environment vars. All you do is call make and everything else is handled by the makefile. This is ideal for C::B as all you have to do is set it to a custom make command, and set the command to "make" with the current directory for the command set to where the makefile is.

antime
Interested
Posts: 22
Joined: Sun Feb 06, 2011 9:18 pm
Contact:

Post by antime » Mon Aug 13, 2012 8:45 pm

Chilly Willy wrote:I've grown to not like environment variables... mainly because I have so many cross compilers that you simply cannot make environment variables to allow them all to work. It's simply not possible.
I don't disagree with defining things in the makefile, but you don't have to put everything in your startup environment either. It's easy to create shell scripts for different environments, and any decent terminal emulator will let you create profiles that read the appropriate script on startup. On Windows, cmd scripts and shortcuts can be used for the same effect.

Also, the toolchain will know its "own" library and include paths, you shouldn't have to specify them separately.

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Tue Aug 14, 2012 6:01 am

antime wrote:
Chilly Willy wrote:I've grown to not like environment variables... mainly because I have so many cross compilers that you simply cannot make environment variables to allow them all to work. It's simply not possible.
I don't disagree with defining things in the makefile, but you don't have to put everything in your startup environment either. It's easy to create shell scripts for different environments, and any decent terminal emulator will let you create profiles that read the appropriate script on startup. On Windows, cmd scripts and shortcuts can be used for the same effect.

Also, the toolchain will know its "own" library and include paths, you shouldn't have to specify them separately.
What I USED to do is have a text file of all the different exports for each toolchain. Then depending on what toolchain I was using, I'd cut and paste those exports into a new shell since each new shell has only the default environment variables.

ammianus
Very interested
Posts: 124
Joined: Sun Jan 29, 2012 2:10 pm
Location: North America
Contact:

Post by ammianus » Sat Sep 01, 2012 11:56 am

antime wrote:
Chilly Willy wrote:I've grown to not like environment variables... mainly because I have so many cross compilers that you simply cannot make environment variables to allow them all to work. It's simply not possible.
I don't disagree with defining things in the makefile, but you don't have to put everything in your startup environment either. It's easy to create shell scripts for different environments, and any decent terminal emulator will let you create profiles that read the appropriate script on startup. On Windows, cmd scripts and shortcuts can be used for the same effect.

Also, the toolchain will know its "own" library and include paths, you shouldn't have to specify them separately.
Just want to point out that running make from within the available C/GCC/Make aware IDEs doesn't seem to have this flexibility. At least I've been looking for one and haven't really found it yet.

ammianus
Very interested
Posts: 124
Joined: Sun Jan 29, 2012 2:10 pm
Location: North America
Contact:

Post by ammianus » Sat Sep 01, 2012 12:07 pm

Chilly Willy wrote:I've grown to not like environment variables... mainly because I have so many cross compilers that you simply cannot make environment variables to allow them all to work. It's simply not possible. So I put all the paths in the makefile. Then the only thing the makefile assumes the path is set for are the host tools like rm or cp. Look at a typical makefile I use now:
...
The first few lines allow for one environment variable, and sets the main path to a default if it's not found (and it won't be on my system). Everything else for the cross compiler has a path based on that and the project spelled out in the makefile with no reliance on environment vars. All you do is call make and everything else is handled by the makefile. This is ideal for C::B as all you have to do is set it to a custom make command, and set the command to "make" with the current directory for the command set to where the makefile is.
I see I have it working like that now. Cool, no dependencies on env variables.

I guess I could put the toolchain commands on the system path, the reason I like that better is that running the tools with their explicit full paths results in long output logs when I run make :)

Edit: Works with Geany!

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Sat Sep 01, 2012 8:13 pm

I use Geany the most of the various editor-IDEs... I rather like it. Not too heavy, but still does most everything you want from an editor-IDE.

ammianus
Very interested
Posts: 124
Joined: Sun Jan 29, 2012 2:10 pm
Location: North America
Contact:

Post by ammianus » Sun Nov 04, 2012 11:44 pm

I don't know if this has already been mentioned in this thread, just a few comments on dependencies. I am trying to rebuild the toolchain on clean install of Ubuntu 12.04.

By default that distro comes with gcc 4.6.3. It is also missing the makeinfo package which is a dependency of the toolchain build. Easy enough to install with sudo apt-get install texinfo. (it's teXinfo, not texTinfo, made that mistake at first). There is another dependency on .7z. But the Archive Manager prompted me to install it automatically.

I also notice there are now newer versions of GMP (5.05) and MPC (1.01) than in the original instructions. Any known pros/cons with using later ones?

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Mon Nov 05, 2012 1:23 am

ammianus wrote:I also notice there are now newer versions of GMP (5.05) and MPC (1.01) than in the original instructions. Any known pros/cons with using later ones?
Shouldn't be. There was a problem with one of the 4.5.x versions with one of those libs where they recommended sticking with an older version of the lib, but I haven't seen a problem with 4.6.x or 4.7.x and the newest version of those libs.

MintyTheCat
Very interested
Posts: 484
Joined: Sat Mar 05, 2011 11:11 pm
Location: Berlin, Germany

Post by MintyTheCat » Tue Dec 04, 2012 7:03 pm

Hello all,

I managed to build a targeted 68K Cross GCC about a Year or so ago. I got Things up and running under Ubuntu.

However, I have decided to manage most of my Tools under FreeBSD.

Has anyone managed to successfully build Chilly-Willy's 68K GCC?

I'm running:
FreeBSD 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:15:25 UTC 2012 root@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386

I am building using gmake.

I was going to try a number of different Versions of GCC, Binutils, GMP, MPC and MPFR to eventually zero in on a set of Versions that build correctly.

I tend to subscribe to the Notion of 'safety in Numbers' when using Toolchains so I'm happy to give Chilly-Willy's Build a try.

We all always have such Fun with GCC and Binutils :D

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Tue Dec 04, 2012 8:39 pm

Not sure if anyone has tried BSD before... I guess if you have the dependencies taken care of, it SHOULD work fine. There have been plenty of people who had no trouble in linux, and a few in Windows using CygWin or MINGW... and a couple using OSX. Please report on how it goes in FreeBSD. If you run into any trouble, we can probably figure out what's going on.

kubilus1
Very interested
Posts: 237
Joined: Thu Aug 16, 2012 2:25 am
Contact:

Post by kubilus1 » Tue Dec 04, 2012 10:05 pm

I've built the environment on FreeBSD pretty recently using the scripts from the other build thread (viewtopic.php?t=1248). For the most part this works, but you will have to specify 'gmake' instead of the default 'make' and alter any scripts that specifically specify 'make'. I thought about having MAKE setup as a variable to make this easier in future.

I think I was able to everything setup except one of the tools, 'bin2c' or 'hex2bin' or something, don't remember exactly.
Last edited by kubilus1 on Wed Dec 12, 2012 7:51 pm, edited 1 time in total.

MintyTheCat
Very interested
Posts: 484
Joined: Sat Mar 05, 2011 11:11 pm
Location: Berlin, Germany

Post by MintyTheCat » Tue Dec 11, 2012 11:34 pm

Guys,

I have just moved house from the South of Germany to the North. I shall try building the Binutils and GCC for FreeBSD once I am settled in.

Thanks for the Support.

kubilus1
Very interested
Posts: 237
Joined: Thu Aug 16, 2012 2:25 am
Contact:

Post by kubilus1 » Wed Dec 12, 2012 8:10 pm

I've updated the scripts in my google code project so you should just have to do:

Code: Select all

  $ MAKE=gmake MGET=fetch gmake
I no longer have my old FreeBSD system but will probably setup a VM to try this again sometime soon.

kubilus1
Very interested
Posts: 237
Joined: Thu Aug 16, 2012 2:25 am
Contact:

Post by kubilus1 » Thu Dec 13, 2012 2:55 pm

Alright everything but zasm should work on FreeBSD now. Tested on FreeBSD 8.3. Just checkout the project and do what I recommend in the previous post. This is tested with the gcc and binutils, through the sgdk setup. Since sgdk uses sjasm instead of zasm, you should still be ok.

Now if someone wanted to donate a Macbook Air, I'll take a look at a Mac build on this ... ;)

Post Reply