lucene-pylucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andi Vajda <>
Subject Re: Unresolved external symbol errors when linking example native c++ code that uses jcc
Date Wed, 27 Oct 2010 17:23:42 GMT

On Wed, 27 Oct 2010, Imre András wrote:

> Andi Vajda <> írta:
>> Using JCC in your project is a two-step process. First get JCC to generate
>> the C++ wraper code for the Java code you want access to. This is,
>> hopefully, well documented on the JCC site [1]. Then take that generated
>> code tree and the necessary JCC runtime source files [2] and add them to
>> your project's build. Any file that includes <Python.h> unconditionally is
>> not part of the code you should include.
> This step is ok.
>> The last problem you found has to do with the fact that the env global
>> variable is declared in a file only needed by the Python runtime; jcc.cpp
>> should not be included in your project and you need to declare that global
>> in code of yours instead.
> In addition to files mentioned under [2], it seems that JArray.h is also
> needed.

JArray.h is also needed, yes, my bad. It has some Python support code but
it's conditionally included.

> As I see JCCEnv.h dllexports JCCEnv *env (_jcc_shared is not defined). The
> link target for my code is an exe, and I keep getting unresolved external
> symbol errors for "class JCCEnv * env".

Yes, as I alluded to earlier, you need to define (and not declare as I said,
sorry), that global variable in your code, most likely near the code you
need to write to initialize and start the JVM.
Basically, you need to write something like the initVM() function defined in
jcc.cpp for Python users. There, you should also define that 'env' global
and set it up with the vm_env you get from JNI_CreateJavaVM() as is done in
that initVM() function.

> At first I tried to hack around, and modify the *env ptr definition (strip
> the dll export), but that resulted in "already defined" errors. I guess the
> last chance is to create a separate project for jcc runtime and its
> generated code with a dll target. Then I would use that with dllimport in
> the code that uses that layer.

Yes, it should be defined once and declared everywhere else as 'extern'.
In your case, _DLL_EXPORT should be '' and the result declaration should
then be equivalent to the non-Windows case just below it (in JCCEnv.h).


  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message