Re: CNI compile error

[Glenn Chambers <gchamber at bright dot net>]

At 03:12 PM 6/28/01 +1200, Bryce McKinlay wrote:
>> The sample [cni-1.txt and cni-2.txt] needs to be fixed, then.
>
>Yes. Its important to #include <cni.h> before any C++ library includes.
>This contains a pragma that sets the compiler to use the Java
>EH personality for the current translation unit. The CNI sample code was
>written before this requirement existed.

Unfortunately, moving the <cni.h> header doesn't fix the problem.

>> I'm still trying to see what practical limitations this imposes on
>> writing native methods.  Is the following a fair accessment?:
>>
>> + No C++ classes that throws or catches (C++) exceptions (e.g.,
>> std::cout) can be used in CNI/JNI native methods.
>
>My understanding is that you can do this provided that both the throw and
>the catch (and possibly, any frames in between) are compiled with the Java
>EH mode, but you can't catch a C++ exception from a separatly compiled
>C++ library. The workaround would be to do the C++ catch in a separate
>source file which does not include cni.h, and call that from your CNI
>source.

This does work.  I'll try to put together a patch to the cni-xxx files
to document this properly.

GCJ Team:  Should I update cni-2.txt to document the 3.0 status, or
keep it as-is, since it more-or-less accurately documents the non-FSF
Red Hat compiler release?  If I keep cni-2.txt as-is, I'll create a
cni-3.txt with the new information.

-- Glenn Chambers
-- Toledo, Ohio
-- gchamber@bright.net