Revision history [back]

I'm augmenting the Java wrapper for OpenCV with some of my own code. In a nutshell here is my build process:

1. On Ubuntu 16.04 I'm building OpenCV (3.4.0) Java wrapper statically linked so that all of the rest of the OpenCV libraries is in the JNI library.
2. I have my own JNI library built as a separate shared library with code against the C++ implementation of OpenCV
3. I explicitly System.load() both shared libraries into my java code.

I have much of it working except one method that seems to trigger the following error

java: symbol lookup error: [path to my library].so: undefined symbol: _ZN2cv6String8allocateEm

This is the cv::String::allocate method from stl.cpp. Using nm on the OpenCV library I can see the symbol is defined as local (indicated by the lower case 't'):

0000000000442990 t _ZN2cv6String8allocateEm

When I run make with VERBOSE=1 I can see that -fvisibility=hidden is being passed to the compiler for stl.cpp.

If this is intentional can someone please let me know what I'm supposed to do. Obviously this will work if I build my code directly into the OpenCV shared library I'm building but I'd prefer not to do that. I'm using the public C++ interface for OpenCV which results in that call being made even though I'm not doing it explicitly. I'm calling imshow from my C++ wrappers.

Any suggestions?

Thanks

I'm augmenting the Java wrapper for OpenCV with some of my own code. In a nutshell here is my build process:

1. On Ubuntu 16.04 I'm building OpenCV (3.4.0) Java wrapper statically linked so that all of the rest of the OpenCV libraries is in the JNI library.
2. I have my own JNI library built as a separate shared library with code against the C++ implementation of OpenCV
3. I explicitly System.load() both shared libraries into my java code.

I have much of it working except one method that seems to trigger the following error

java: symbol lookup error: [path to my library].so: undefined symbol: _ZN2cv6String8allocateEm

This is the cv::String::allocate method from stl.cpp. Using nm on the OpenCV library I can see the symbol is defined as local (indicated by the lower case 't'):

0000000000442990 t _ZN2cv6String8allocateEm

When I run make with VERBOSE=1 I can see that -fvisibility=hidden is being passed to the compiler for stl.cpp.

If this is intentional can someone please let me know what I'm supposed to do. do? Obviously this will work if I build my code directly into the OpenCV shared library I'm building but I'd prefer not to do that. I'm using the public C++ interface for OpenCV which results in not explicitly calling that call method so it's being made even though I'm not doing it explicitly. I'm called indirectly from what I am calling (which is imshow from my C++ wrappers.).

Any suggestions?

Thanks

I'm augmenting the Java wrapper for OpenCV with some of my own code. In a nutshell here is my build process:

1. On Ubuntu 16.04 I'm building OpenCV (3.4.0) Java wrapper statically linked so that all of the rest of the OpenCV libraries is in the JNI library.
2. I have my own JNI library built as a separate shared library with code against the C++ implementation of OpenCV
3. I explicitly System.load() both shared libraries into my java code.

I have much of it working except one method that seems to trigger the following error

java: symbol lookup error: [path to my library].so: undefined symbol: _ZN2cv6String8allocateEm

This is the cv::String::allocate method from stl.cpp. Using nm on the OpenCV library I can see the symbol is defined as local (indicated by the lower case 't'):

0000000000442990 t _ZN2cv6String8allocateEm

When I run make with VERBOSE=1 I can see that -fvisibility=hidden is being passed to the compiler for stl.cpp.

If this is intentional can someone please let me know what I'm supposed to do? Obviously this will work if I build my code directly into the OpenCV shared library but I'd prefer not to do that. I'm not explicitly calling that method so it's being called indirectly from what I am calling (which is imshow).

Any suggestions?

Thanks

I'm augmenting the Java wrapper for OpenCV with some of my own code. In a nutshell here is my build process:

1. On Ubuntu 16.04 I'm building OpenCV (3.4.0) Java wrapper statically linked so that all of the rest of the OpenCV libraries is in the JNI library.
2. I have my own JNI library built as a separate shared library with code against the C++ implementation of OpenCV
3. I explicitly System.load() both shared libraries into my java code.

I have much of it working except one method that seems to trigger the following error

java: symbol lookup error: [path to my library].so: undefined symbol: _ZN2cv6String8allocateEm

This is the cv::String::allocate method from stl.cpp. Using nm on the OpenCV library I can see the symbol is defined as local (indicated by the lower case 't'):

0000000000442990 t _ZN2cv6String8allocateEm

When I run make with VERBOSE=1 I can see that -fvisibility=hidden is being passed to the compiler for stl.cpp.

If this is intentional can someone please let me know what I'm supposed to do? Obviously this will work if I build my code directly into the OpenCV shared library but I'd prefer not to do that. I'm not explicitly calling that method so it's being called indirectly from what I am calling (which is imshow).

__EDIT:__ It doesn't link on Windows at all. On Linux it leaves the symbols and "undefined" and my code path doesn't require it but one Windows it wont link. it seems to me that this means anyone creating a shared library that uses OpenCv wont be able to link on Windows ore run on Linux.

Any suggestions?

Thanks

I'm augmenting the Java wrapper for OpenCV with some of my own code. In a nutshell here is my build process:

1. On Ubuntu 16.04 I'm building OpenCV (3.4.0) Java wrapper statically linked so that all of the rest of the OpenCV libraries is in the JNI library.
2. I have my own JNI library built as a separate shared library with code against the C++ implementation of OpenCV
3. I explicitly System.load() both shared libraries into my java code.

I have much of it working except one method that seems to trigger the following error

java: symbol lookup error: [path to my library].so: undefined symbol: _ZN2cv6String8allocateEm

This is the cv::String::allocate method from stl.cpp. Using nm on the OpenCV library I can see the symbol is defined as local (indicated by the lower case 't'):

0000000000442990 t _ZN2cv6String8allocateEm

When I run make with VERBOSE=1 I can see that -fvisibility=hidden is being passed to the compiler for stl.cpp.

If this is intentional can someone please let me know what I'm supposed to do? Obviously this will work if I build my code directly into the OpenCV shared library but I'd prefer not to do that. I'm not explicitly calling that method so it's being called indirectly from what I am calling (which is imshow).

__EDIT:__ __EDIT__ It doesn't link on Windows at all. On Linux it leaves the symbols and "undefined" and my code path doesn't require it but one Windows it wont link. it seems to me that this means anyone creating a shared library that uses OpenCv wont be able to link on Windows ore run on Linux.

Any suggestions?

Thanks

I'm augmenting the Java wrapper for OpenCV with some of my own code. In a nutshell here is my build process:

1. On Ubuntu 16.04 I'm building OpenCV (3.4.0) Java wrapper statically linked so that all of the rest of the OpenCV libraries is in the JNI library.
2. I have my own JNI library built as a separate shared library with code against the C++ implementation of OpenCV
3. I explicitly System.load() both shared libraries into my java code.

I have much of it working except one method that seems to trigger the following error

java: symbol lookup error: [path to my library].so: undefined symbol: _ZN2cv6String8allocateEm

This is the cv::String::allocate method from stl.cpp. Using nm on the OpenCV library I can see the symbol is defined as local (indicated by the lower case 't'):

0000000000442990 t _ZN2cv6String8allocateEm

When I run make with VERBOSE=1 I can see that -fvisibility=hidden is being passed to the compiler for stl.cpp.

If this is intentional can someone please let me know what I'm supposed to do? Obviously this will work if I build my code directly into the OpenCV shared library but I'd prefer not to do that. I'm not explicitly calling that method so it's being called indirectly from what I am calling (which is imshow).

__EDIT__ __EDIT:__ It doesn't link on Windows at all. On Linux it leaves the symbols and "undefined" and my code path doesn't require it but one Windows it wont link. it seems to me that this means anyone creating a shared library that uses OpenCv wont be able to link on Windows ore run on Linux.

Any suggestions?

Thanks

I'm augmenting the Java wrapper for OpenCV with some of my own code. In a nutshell here is my build process:

1. On Ubuntu 16.04 I'm building OpenCV (3.4.0) Java wrapper statically linked so that all of the rest of the OpenCV libraries is in the JNI library.
2. I have my own JNI library built as a separate shared library with code against the C++ implementation of OpenCV
3. I explicitly System.load() both shared libraries into my java code.

I have much of it working except one method that seems to trigger the following error

java: symbol lookup error: [path to my library].so: undefined symbol: _ZN2cv6String8allocateEm

This is the cv::String::allocate method from stl.cpp. Using nm on the OpenCV library I can see the symbol is defined as local (indicated by the lower case 't'):

0000000000442990 t _ZN2cv6String8allocateEm

When I run make with VERBOSE=1 I can see that -fvisibility=hidden is being passed to the compiler for stl.cpp.

If this is intentional can someone please let me know what I'm supposed to do? Obviously this will work if I build my code directly into the OpenCV shared library but I'd prefer not to do that. I'm not explicitly calling that method so it's being called indirectly from what I am calling (which is imshow).

__EDIT:__ It doesn't link on Windows at all. On Linux it leaves the symbols and "undefined" and my code path doesn't require it but one on Windows it wont link. it It seems to me that this means anyone creating a shared library that uses OpenCv wont be able to link on Windows ore run on Linux.

Any suggestions?

Thanks