H8 Compiler for Win32

["Michael K. Elwood" <mkelwood@qsicorp.com>]

Well, for those who are interested:

I've been working on compiling EGCS 1.1.1 as a cross-compiler
targetting Hitachi H8/300 controllers and hosted on NT (mingw32).

I did get some semblance of a working compiler, but the road was
treacherous and fraught with peril.

Since the EGCS 1.1.1-mingw32 binary distribution from Mumit
doesn't include bash, sed and a few other necessaries, I decided
to use Cygwin B20.1 for building the compiler. Hoping to eliminate
dependance on Cygwin1.dll, I tried a Canadian cross by specifying
the host as i586-pc-mingw32 and the target as h8300-hms.

Configuring binutils 2.9.1 was pretty painless. It croaked on the build,
however. The problem is in the makefile in /binutils. The
SRCONV_PROG variable is defined as 'srconv sysdump coffdump',
with 3 binary targets specified in the same variable. The
mingw32 config tacks the '.exe' extension on the end of this
variable to specify names for the Win32 executables. This would
work great if SRCONV_PROG had only one program name in it.
As it is, make complains that it doesn't know how to build 'srconv'.

At this point, I just build these 3 programs one at a time by specifying:

make srconv.exe

etc.

Now make complained that it didn't know how to build '.exe'. Argh!
Now I tried hacking the makefile; I'm not autoconf expert, but it seems
like the configuration wouldn't accept my hack if any of the source
was built before the makefile was changed.

In the end, I just reconfigured, changed the line in the makefile that reads

SRCONV_PROG=srconv sysdump coffdump

to

SRCONV_PROG=srconv.exe sysdump.exe coffdump

and built the source. It worked fine this time. I know this is an ugly
hack, and somebody who knew their autoconf could do a
better job. Any takers?

Now building the compiler proper:

I basically followed Randy Loomis' directions for building a linux-hosted
H8/300 cross compiler (posted a few days ago). Again I configured for
an NT mingw-32 host and a h8300-hms target. I also linked the newlib
source tree as a subdir to the EGCS source tree, as he suggested, so
that the library would be built automatically.

This is where I hit the snag with the 'environ' variable. I hacked toplev.c
to exclude this variable from the build. 'environ' appears in a couple
other places, but it doesn't make it into the build due to other exclusions.

Now the compiler seemed to build properly, but the library build crashed.
I installed the compiler, but it didn't install the cpp.exe, cc1.exe and
cc1plus.exe files into the target bin directory. I had to copy those
over manually.

The library build still crashed, do I tried configuring newlib separately
and building with the new compiler binaries directly. Still no go. Every
time I tried to build it, it would go on and on reconfiguring for several
minutes, then complain that it couldn't find some part of the compiler.
I gave up and just used the libraries from the go32 version of the
H8 cross compiler.

I now have an oddly built but functional Win32 cross compiler for the
H8. It compiles properly and runs MUCH faster than the go32 version
on NT. When I examined the binaries, however, I was disappointed to
see that they still import large chunks of Cygwin1.dll, instead of
crtdll.dll.
Apparently specifying Mingw32 as the host didn't quite come through in
the build. Oh well, I'll fight that battle another day.

Some questions:

Why didn't 'make install' copy some critical parts of the compiler to the
target bin directory? Also, do I need to prepend "h8300-hms-" to the
front of cpp.exe, cc1.exe and cc1plus.exe, as was done for the other
executables? Perhaps this would explain why the library wouldn't
build, but I know the compiler works as it is; I've built several H8
projects with it.

Why didn't the binaries import crtdll.dll instead of cygwin1.dll?

Regarding the new Make 3.77 Mingw32 binary from Mumit's FTP site: it
repeatedly crashed if I called a DOS executable from inside the makefile.
The Make 3.75 distributed with Cygwin B20.1 doesn't show this same
behavior, but it does slow way down when you call a DOS executable
(probably to start NTVDM). I have since gotten rid of the DOS program
calls, and Make 3.77 seems to work fine now.

Also, neither Make deals very well with non-bash shells (like
cmd.exe and 4nt.exe). Why is this?

Best regards,

MKE

#####################################
Michael K. Elwood  Phone: 801-466-8770
QSI Corporation  Fax: 801-466-8792
email:  mkelwood@qsicorp.com

Opinions are mine, not QSI's, etc. etc.

    "I don't believe in violence. I don't
            even believe it exists."
                            - Black Sabbath Vol. 4
#####################################


_______________________________________________
New CrossGCC FAQ: http://www.objsw.com/CrossGCC
_______________________________________________
To remove yourself from the crossgcc list, send
mail to crossgcc-request@cygnus.com with the
text 'unsubscribe' (without the quotes) in the
body of the message.