Can't compile for H8 tiny

[tsm]

Binary package hint: gcc-h8300-hms

The repo version of the compiler does not seem to have a libgcc.a that is compatible with the -mn option required for h8 tiny devices.

[Kagetsuki (zero-tsuki)]

Same thing going on here, but I'm targeting an H8/3069.
I believe I have properly analyzed the problem at this point, though I have not yet been able to fix it. Here's what I've come up with:
1. The package maintainer did not build GCC with newlib as he could not get it to build (I found a post stating this somewhere but can't seem to relocate it).
2. As newlib provides the C libraries (libc.a, not libgcc.a mind you).
3. I have successfully built newlib (1.17.0) and incorporated it into the directory structure, but I get the error
=============================================
/usr/lib/gcc/h8300-hitachi-coff/3.4.6/../../../../h8300-hitachi-coff/bin/ld: skipping incompatible /usr/lib/gcc/h8300-hitachi-coff/3.4.6/../../../../h8300-hitachi-coff/lib/libc.a when searching for -lc
/usr/lib/gcc/h8300-hitachi-coff/3.4.6/../../../../h8300-hitachi-coff/bin/ld: skipping incompatible /usr/bin/../h8300-hitachi-coff/lib/libc.a when searching for -lc
/usr/lib/gcc/h8300-hitachi-coff/3.4.6/../../../../h8300-hitachi-coff/bin/ld: cannot find -lc
collect2: ld returned 1 exit status
=============================================
indicating my build of newlib is not compatible with the compiler/assembler/linker/etc. Everything was built with the H8300 compiler/assembler/linker according to the build log. Further poking around with google provided me with some comments about how newer versions of GCC don't have ports properly updated. In a fit of desperation earlier on in my venture here I grabbed gcc-4.4 sources and tried to build only to find a message about the target h8300 no longer being maintained and that it has been deprecated and will be removed....

Has anyone been able to build for H8 with newer versions of Ubuntu? What was the last successfully build anyone had? What version of the packages was that with?

[tsm (sbattazz)]

Kagetsuki,

I was able to build GCC for H8 from source in Ubuntu 8.10, and I used GCC 4.1.1 if I remember correctly.
When I upgraded to 8.10, GCC 4.3 was on the system by default, which gave me all sorts of issues when trying to build the 4.1, so as a kludgey workaround I installed GCC 4.1 from the Ubuntu repo and temporarily pointed bash at it so I could use it to build my cross compiler.

I can't recall what versions of newlib I used right now because I'm on a new machine, but I can let you know later if you're interested. It might have been 1.16 or 1.17...

When I was first setting up my H8 environment, I had two issues that were sort of independently causing the incompatible libgcc.a problem.

1. I first tried the version in the repo, which did not work at all
2. I had issues with my compile options, crt0.s and h8rom.x; basically, to compile for a tiny (3694F) I needed to have the -mn option in my compile command, and the tiny architecture specified in the support files... it took some poking around to figure this out. I don't think this applies to your 3069

It's a shame to hear that they're dropping the H8 target support, but on the other hand I don't see any problem with using an older version of GCC for chips like this as long as no new bugs pop up (knock on wood).
I might actually just try to stay away from H8 if I can get away with it :)

[Kagetsuki (zero-tsuki)]

I wonder why a non-working version is in the repositories to begin with.

For my application I need to use the 3069 because that's what is on the board I need to develop on. This is the first time I've developed on an H8 since I was in school, and at that point the tool chain was a snap to build. It's a shame it's no longer maintained. I grabbed the newest version from 秋月電子 today from a friend to see if that would work, binutils built but gcc refused to configure because my system is AMD-64 which is an unknown architecture for that version. I'm running the windows version in a virtualbox install now, which is less than preferable but I'll make do for now. I'd consider HEW but that would blow my budget and betray my love for the GNU toolchain.

 Depending on your application moving to AVR may not be hard at all, and the GNU toolchain for AVR is very well developed and the packages are all there in the repositories. It's hard to compare core architectures for the H8 and AVR, but I'd say AVR and H8 occupy the top positions in the 8-bit arena in terms of core efficiency. However, if you have an application that requires a particular feature, like DMA or CAN, or an embedded OS like uITron or HOS the AVR devices that support such features are limited in number compared to the H8 series. If your application isn't dependent on particular features not found in AVR I would recommend grabbing a programmer (the AVR-ISP II ran me something like 4,000 yen, and even the most full featured programmers will not run you much more than about 30,000 yen I believe). Writing to the chips and interfacing with them is quite different, but if you are just writing flash with a simple programmer you don't need to worry about run modes and what not. You can actually continually write to flash on a live circuit without touching it, and it resets after each write so it makes real world adjustment and debugging a pleasure. I really wish Renesas would embrace the Open Source/GNU community as much as Atmel has.