Need Feedback: ${target_alias}-gcjh for native builds?

Mon Nov 10 03:56:00 GMT 2003

Hi Bryce,
Thanks for replying to this.
>> Wouldn't it make sense to make a ${target_alias}-gcjh
>> for native builds for the same reason we have
>> ${target_alias}-gcj, -gcc, etc. for native builds?
>>As far as I'm aware, gcjh-generated headers should not be 
>target-specific in any way, so I'm not sure it makes sense to have a 
>target-specific gcjh. Do you have an example where it would be useful?

My mind is a little fried right now, but I'll take a swing at
answering this anyway. If I'm not coherent enough,
we'll have another go at it tomorrow.
(
For those reading this that don't understand "cross",
"crossed-native", etc., see this link that Ranjit
gave me when I was young and impressionable:
http://gcc.gnu.org/onlinedocs/gccint/Configure-Terms.html
)
When dealing with native, cross and crossed-native
builds, there are situations where I have multiple
compilers in my path. Let's take the example of a
crossed-native build (where I am using a cross compiler
to build a native compiler). I have two compilers in
my path: the native (build) compiler and the cross
compiler. When generating the headers used by the (crossed-native)
compiler, I want to use the gcjh of the cross compiler.
Yes, gcjh-generated headers should not be target specific,
but don't forget that gcjh has to parse the classfile
and there might be bugs in my build compiler gcjh which
are fixed in the cross-compiler gcjh. Just like I use
the cross gcj with -C to generate the classfiles,
I want to use the cross gcjh to generate the
headers.
As it turns out, the cross gcjh is correctly named
${target-alias}-gcjh.
Now let's say I want to create a portable Makefile
to build something for Windows which uses gcj and
gcjh. I want the makefile to work unchanged on Linux
(where I'd use the cross compiler) and Windows
(where I'd use the native compiler). The native Windows
compiler gives me both gcj.exe as well i686-pc-mingw32-gcj.exe
so I can use the makefile unchanged for every scenario
except for gcjh, where I don't have a native i686-pc-mingw32-gcjh.exe.
Yes, I could pray that there's some other non-buggy,
up-to-date gcjh somewhere in my path, but this is
breaking encapsulation.
In my above arguments, I don't think I was as concise
and to-the-point as I could have been, but it's
because I'm too tired to corral these thoughts into
one place. Hopefully, you got my point.
-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/