I am facing a situation of which I have no idea. I am tried to test one method that I have implemented in C++ and I used swig to generate the wrapper. After compilation, when I tried to run the application, I got an error java.lang.UnsatisfiedLinkError.
It further states that
cannot load library:reloc_library[1311]:33
cannot locate '_Z13recognizeFacePKcS0_'
...
and suddenly throw exception.
I tried using adb shell to debug and found library in the right location (data/data/com/mesh/faceAuth/lib/libfaceAuth.so) but it gives the same error. I also read from this site, that it has to do with wrong STL implementation which I don't have any clue of. I will highly appreciate your candid suggestion.
Regards,
Mohammed.
Best guess with what information you have provided, The library you are trying to load needs some dependencies to be loaded before it.
For example:
System.loadLibrary("bullet");
System.loadLibrary("irrlicht");
System.loadLibrary("gamescript");
gamescript library needs other 2 library to be loaded before it. Otherwise, it gives me the same error you have mentioned. I can dig further on this issue if you can post some part of your .mk file for building the library here.
Your error has nothing to do with STL.
You probably reference a global function ::recognizeFace(char const*, char const*) in your code. Maybe, you have another function defined, for example recognizeFace(char*, char*).
Related
I am trying to add an external FORTRAN Code to OpenModelica 1.13.0. My function and model definitions are correct and the FORTRAN code normally works. But whenever I add a write(*,*) or read(*,*) method to the code I get the following error as OpenModelica Simulation output:
undefined reference to _gfortran_transfer_real_write##GFORTRAN_1.4
I wonder how can I solve this issue.
Thank you.
This (probably) happens because you are not linking gfortran with the simulation. If the library is shared (so, DLL, dylib), the dependency is usually handled automatically, so you are probably trying to link a static library (.a) or object file (.o, .obj).
In your external function, add an annotation Library="gfortran" or since you probably already have your library in there, Library={"mylib", "gfortran"}.
Also note that OpenModelica 1.13 is getting old and should be upgraded.
For OMShell one can call the setCFlags("-lgfortran") or inside OMEdit add -lgfortran at Simulation Setup > General > C/C++ Compiler Flags. It will solve the issue.
I followed all the instructions provided in the docs/msw/install.txt file for building wxWidgets 3.0.2 using cygwin with all the necessary tools installed.
And even after using the configure script with all the different possible options.
But still it doesn't build properly.The configure script executes correctly but when i use make it shows me this error.
Error:
cannot convert ‘wxString’ to ‘const void*’ for argument ‘2’ to ‘ssize_t cygwin_conv_path(cygwin_conv_path_t, const void*, void*, size_t)’
cygwin_conv_path(CCP_POSIX_TO_WIN_W, strDir, windowsPath, MAX_PATH);
If any one can help me on this i will highly appreciate it.
Thank you.
First of all, are you absolutely sure that you really want to use the Cygwin port of wxWidgets? This is almost never a good idea and it's strongly recommended to use Cygwin as the build environment for building the native MSW port using MinGW (cross-)compiler as explained in this post.
If you really do need Cygwin, it looks like you need to insert .c_str() call here, i.e. write cygwin_conv_path(CCP_POSIX_TO_WIN_W, strDir.c_str(), windowsPath, MAX_PATH), as you're probably using --enable-stl and the implicit conversion is not available.
If you write a C++/CLI application, and you attempt to use STL:CLR via cliext and you typedef for example a cliext map then you will find that it doesn't work due to a LNK2022 error.
I was mistaken in my original answer on how to mitigate the link error as pointed out by Hans in the comment above. Though, he does recommend using Dictionary instead, it is still possible to continue using cliext and solve the problem without unusual workarounds.
The actual answer is that templates do not allow external linkage. This means that somewhere I was using the cliext::map outside of my namespace. The moment that was eliminated, the link error goes away.
I'm trying to link my XPCOM extension against the 1.9.3a3pre SDK and I get the following:
error LNK2001: unresolved external symbol _moz_xmalloc
So, what lib do I need to link to? The documentation doesn't say.
This is on Windows right now, but I'll need it to build on Mac and Linux (32bit/64bit) as well.
Edit: Now with bounty.
Edit: Update: Turns out FF3.7 was cancelled. So I don't have to worry about this until FF4.
I have same error, and linking to mozalloc helps for that.
define 'XPCOM_GLUE' in C++ Preprocessor Definition property. It will fix the linking error.
Try defining MOZ_NO_MOZALLOC when compiling your extension, you will then get a DLL that uses your CRT's allocators. (Don't forget to use the NS_* allocators for XPCOM-compatible memory.)
Add MOZ_NO_MOZALLOC in C++->Preprocessor->Definition property.
Use xpcomglue_s_nomozalloc.lib instead of xpcomglue_s.lib in Linker->Input->Additional Dependencies
It will be OK!
reminder note: another option that can cause this even though everything else seems to be configured correctly in the project, is pointing at the wrong libs folder - such as 32 bit version for a 64 bit build.
edit v40 mozalloc.lib has changed name to mozglue.lib and has some additional methods.
edit v41 mozglue.lib has changed name to mozcrt.lib
I saved my VB-Express code as .dll and registered it with regasm and made a .tlb file.
But when I try to run a function from it in an Excel-modul I get: Run-time error ‘453’: Can’t find DLL entry point RegisterServiceProcess in kernel32
What step did I miss?
See http://richnewman.wordpress.com/2007/04/15/a-beginner’s-guide-to-calling-a-net-library-from-excel/
or better still try out ExcelDNA ( http://groups.google.com/group/ExcelDna )
I think you're creating a .Net dll and trying to call it from a COM-oriented environment (VBA), which isn't going to work without help. If I'm guessing right, then you need to investigate the COM Interop elements of .Net: Google throws up lots of promising-looking links, one of which is this article.
It looks a bit unpleasant, but I expect the nastiness can be tucked away somewhere...
Try this Microsoft Knowledge Base article: Can't Run Macro That Calls 16-bit DLL in 32-bit MS Excel.
Do you have the proper rights to access the DLL?
Thanks for the input to everybody, you helped me a big step further.
After following the guides you provided I got: Run-time error: '-2147024894' (80070002)': File or assembly name AssemblyName, or one of its dependencies, was not found.
But I could fix that with this Workaround.