I'd like to load a pytorch model weight & bias **.pt in android ndk project. I used pytorch mobile anddorid library to parse the model. When I used torch::load api, it cause linked error:
headers/torch/csrc/api/include/torch/serialize.h:130: undefined reference to `torch::serialize::InputArchive::InputArchive()
headers/torch/csrc/api/include/torch/serialize.h:131: undefined reference to `torch::serialize::InputArchive::load_from()
headers/torch/csrc/api/include/torch/serialize.h:139: undefined reference to torch::serialize::InputArchive::try_read()
.Then I used torch::jit::load to parsed, but got execution error:
terminating with uncaught exception of type c10::Error: torch::jit::load() received a file from torch.save(), but torch::jit::load() can only load files produced by torch.jit.save()
Maybe the reason is this. C++ frontend api currently only supports loading jit saved tensor file. So the only solution is torch.load then torch.jit.save in python
Related
I am currently having an issue with trying to use the -mlarge flag with the MSPGCC compiler on an MSP430, its throwing the following error for all the generated objects in my code:
/user/local/ti/msp430-gcc/bin/../lib/gcc/msp430-elf/9.3.1/../../../../msp430-elf/bin/ld: error: /home/ewheatland/repos/Embedded/driverlib/MSP430FR2xx_4xx/lib/adc.o uses the small code model whereas /usr/local/ti/msp430-gcc/bin/../lib/gcc/msp430-elf/9.3.1/../../../../msp430-elf/lib/large/crt0.o uses the large code model
I believe this is due to -msmall being the default configuration however Im not sure how to change it to -mlarge when compiling.
Ive currently tried passing the flag -mlarge to the linker as well using: -Wl,-mlarge however that ended up not being a valid flag for the linker.
All my Vulkan SDK paths are sourced in .profile and give the following results when echoed:
I can enumerate all layers and the application compiles without problems. However, when I run it, I get the following error messages from the debug report callback:
I'm on Ubuntu 17.10 with a GTX 1060 with the 387.42.05 drivers, which support Vulkan 1.1.
Running the application with LD_DEBUG=libs shows 2 errors:
/lib/x86_64-linux-gnu/libpthread.so.0: error: symbol lookup error: undefined symbol: pthread_setname_np, version GLIBC_2.2.5 (fatal)
/home/jesta88/Vulkan/VulkanSDK/1.1.70.1/x86_64/lib/libVkLayer_parameter_validation.so: error: symbol lookup error: undefined symbol: vkNegotiateLoaderLayerInterfaceVersion (fatal)
I have no idea what to make of these errors.
I can't completely explain the first error, although I can reproduce it. It is preceded by
calling init: /usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.0
so I suspect that the nvidia driver is probing for a symbol and fails to find it. Although this is marked as "fatal", it isn't really.
For the second error, I can see that too. I reproduced it by running the build_examples.sh script in the SDK. Then:
cd examples/build
LD_DEBUG=libs ./cube --validate -c 300 2> log
The app runs fine.
To convince myself that the validation layers are loaded and working, I created a validation error by commenting out the call to vkDestroyDescriptorPool (line 2252 in cube.c) and got the expected validation errors.
In this case, I think that the Vulkan loader is trying to look up the vkNegotiateLoaderLayerInterfaceVersion symbol in the driver and failing to find it. This is not a fatal condition either since the export of this symbol by a driver is optional. If the loader does not find the symbol, then it assumes a particular protocol between the loader and the driver. If the symbol does exist, the loader calls it to get additional information about the loader<->ICD interface that the driver supports.
Some more detail can be found in this document.
In short, I don't think that these are actual problems.
Edit: The vkNegotiateLoaderLayerInterfaceVersion issue is really happening when the loader attempts to load a layer, and not the ICD (driver), but the same explanation still applies.
I still can't explain the messages you are getting about not finding the layers.
I suggest setting VK_LOADER_DEBUG=all to get some detailed messages about what the Vulkan loader is doing while it is looking for the layers.
Also, try running the cube demo as I outlined above to see if that app runs correctly.
How to solve this issue? I saw no cholmod_camd related header file in the c++ file I was trying to mex.
Invalid MEX-file '/home/mpelang/Desktop/APAPstitch/Image Stitching with
Bundled Moving
DLT/ceresRigidError.mexa64': /usr/local/lib/libceres.so: undefined
symbol:
cholmod_camd
Ceres solver needs Cholesky methods for solving the linear systems. Either link the c++ file against a library containing cholmod_camd (with -lcholmod -lmwlapack) or explicitly tell ceres you have no cholmod (when building ceres using cmake). Take a look at http://ceres-solver.org/installation.html for how to install Ceres-solver.
I swear I saw a new feature in a recent set of GHC release notes - but now I can find no reference to it. Am I delusional, or does this feature actually exist?
It was to do with loading incomplete modules. As best as I can remember, it allows you to turn off compilation errors due to undefined variables. (Naturally, at run-time this causes an exception to be thrown if you try to actually use the undefined variables for anything.) Does that sound familiar? Or is my mind making this up?
You are looking for a compile time option, vs a language extension, of "defer errors to runtime". That is, compile with -fdefer-type-errors.
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*).