Building A Gcc 4.5 Cross-compiler For The Sharp Rom? Options

[cybersphinx]

Since gcc 2.95 is getting a bit old, and 4.5 has interesting new things like whole program link time optimization, I've though about building a gcc 4.5 cross-compiler to complement g++ 2.95 (which can't be replaced because of the ABI). The problem is, there doesn't seem to be much documentation about how to actually build a cross-compiler for the Zaurus (maybe there was more five years ago). Has anyone every tried this (probably not with 4.5, but maybe some older version)? Are there any docs on how to build any cross-compiler for the Sharp ROM, or have people always just used the premade packages?

[koan]

I think the majority of people use the tool chains that are already available.

I am using the quantumstep chain (http://www.lucid-cake.net/osx_arm/index_en.html) because I am using a Mac. IIRC Andreas said that he had followed the instructions of http://frank.harvard.edu/~coldwell/toolchain/

There is also this: http://www.ailis.de/~k/archives/19-ARM-cro...ling-howto.html

I think the main reason why people don't try to build a more up to date gcc is to do with setting up a two libc system. Another reason is that they are not interested in such old kernels when you can go for another distro, e.g. Debian or zubuntu and immediately switch to a 2.6 kernel.

[cybersphinx]

I think the majority of people use the tool chains that are already available.

Sure, that's easier. I vaguely remember people playing with gcc 3.x for the Sharp ROM years ago though, but I couldn't find any docs about this now.

I think the main reason why people don't try to build a more up to date gcc is to do with setting up a two libc system.

Hm, does that mean if I get gcc 4.5 to work, I can't link g++ 2.95 and gcc 4.5 object files (either directly or as dynamic libraries)? That was really the main point of this, if I can use gcc 4.5 only for pure C programs (or maybe C++ programs that don't depend on anything already on the Sharp ROM), it's not worth the effort.

Another reason is that they are not interested in such old kernels when you can go for another distro, e.g. Debian or zubuntu and immediately switch to a 2.6 kernel.

Yeah, but my main use for the Zaurus is still as a dictionary with Kanji handwriting recognition, so I'm stuck with the Sharp ROM.

[koan]

Hm, does that mean if I get gcc 4.5 to work, I can't link g++ 2.95 and gcc 4.5 object files (either directly or as dynamic libraries)?

I'm no expert but you can't mix files that use a different ABI, you need a libc for each ABI.

Yeah, but my main use for the Zaurus is still as a dictionary with Kanji handwriting recognition, so I'm stuck with the Sharp ROM.

You can run zbedic on zubuntu and use scim with the tomoe module http://scim-imengine.sourceforge.jp/hiki.cgi?SCIMTomoe

The engine used in Kanji Nirvana was a simple port from somewhere else, so you could even take that to write your own input method.

[cybersphinx]

I'm no expert but you can't mix files that use a different ABI, you need a libc for each ABI.

On a Debian etch system (the last one with gcc-2.95), I can link gcc 4.1 object files into g++ 2.95 C++ programs, so basically it should work. The question is, does that work for the Zaurus as well, and if yes, how do I get a compiler for it?

You can run zbedic on zubuntu and use scim with the tomoe module http://scim-imengine.sourceforge.jp/hiki.cgi?SCIMTomoe

The engine used in Kanji Nirvana was a simple port from somewhere else, so you could even take that to write your own input method.

Last time I looked into alternatives (unfortunately, I only have one Zaurus that needs to work, so I'm not very inclined to experiment with reflashing it), those all were pretty basic, requiring kanji to be input one by one, with each stroke separately in the right order. While the Sharp ROM gives me a screen-wide area where I can write whole words, and as long as the stroke order is mostly correct, it recognizes almost everything.

[koan]

Are you really sure you linked gcc 4.1 object files to 2.95 programs ? GCC changed the ABI around ~3.0. Maybe if you used a pure C interface and rentrant code, but C++ ??? I'm very sceptical.

While the Sharp ROM gives me a screen-wide area where I can write whole words, and as long as the stroke order is mostly correct, it recognizes almost everything.

Is that a Sharp specific IM or is it available through Opie ?

[cybersphinx]

Are you really sure you linked gcc 4.1 object files to 2.95 programs ? GCC changed the ABI around ~3.0.

The C++ ABI, yes. But the C ABI has been the same for ages, afaik.

Maybe if you used a pure C interface and rentrant code, but C++ ??? I'm very sceptical.

Well, I tried something like

CODE

file1.c:
int test(int i) {
        return i * i;
}

CODE

file2.cpp:
extern "C" {
  int test(int);
}

void main(void) {
        cout << " x " << test(3) << " y " << endl;
}

CODE

gcc-4.1 -c file1.c
g++-2.95 -c file2.cpp
g++-2.95 -o test file1.o file2.o

which works as expected.

Is that a Sharp specific IM or is it available through Opie ?

It's one of the Sharp ROM's default Japanese input methods, only available in binary form. It might work on OPIE if that's compiled with g++ 2.95 (for the old ABI), but afaik all OPIE systems use newer toolchains.

[koan]

which works as expected.

I'm sorry to be a sceptic still but how do you gain the benefit of link time optimisation if you are linking with the old 2.95 ?

[cybersphinx]

I'm sorry to be a sceptic still but how do you gain the benefit of link time optimisation if you are linking with the old 2.95 ?

Heh, good question actually. From what I read, it works for dynamic libraries. I thought to do the same for static libraries, but that seems not possible. Anyway, that's not the only thing I hope gcc 4.5 is better with, it also should have a generally better optimizer, and support for the Xscale architecture.

[koan]

It looks like someone has already done this with gcc 3.4... see http://prudentialscatterbrain.hp.infoseek.co.jp/

Binaries compiled with his gcc may need a static libgcc and libstdc++ which he supplies in ipks.

(He says that the files in the first table are compiled with his gcc 3.4 but don't need the additional libraries, files in the second table do).

HTH