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.
Related
I get the following error when I try to install Mininet:
Installing Mininet core
~/mininet ~
cc -DVERSION=\"PYTHONPATH=. bin/mn --version\" mnexec.c -o mnexec
mnexec.c: In function ‘setns’:
mnexec.c:49: error: ‘__NR_setns’ undeclared (first use in this function)
I searched online and found that I could fix the problem by defining the missing system call number appropriately for my 32- or 64-bit kernel.
How do I define the missing system call number for the 32-bit kernel?
I do not know what Mininet is, but I believe your problem may be due to lack of a necessary header file. The error:
mnexec.c: In function ‘setns’: `mnexec.c:49: error: ‘__NR_setns’ undeclared (first use in this function)
Indicates that __NR_setns is not declared in what you are attempting to compile. A little digging shows the possible headers in which it is referenced in Linux. See Linux Cross Reference. A short list of possibilities is:
/usr/include/asm/unistd_32.h
/usr/include/asm/unistd_64.h
/usr/include/bits/syscall.h
/usr/include/valgrind/vki/vki-scnums-x86-linux.h
/usr/include/valgrind/vki/vki-scnums-amd64-linux.h
There are others, but those look the most relevant.
one way is to do so is to build the kernel sources again with making original module loadable which need to be modified. so original module can be removed and modified module can be inserted. but this is time consuming process.
I am wondering if there is some other way to load modified module.
I made some modification in MD driver and tried to load it on precompiled kernel.
insmod failed with following error messege:
md_mod: exports duplicate symbol bitmap_close_sync (owned by kernel)
insmod: error inserting 'md-mod.ko': -1 Invalid module format
Please provide the feedback if it can be done. Any help would be appreciated. Thanks !
This error shows up because already the bitmap_close_sync symbol is exported by the kernel, again you are trying to re-export the same symbol in md_mod module. Try not to export the symbol, compile and try inserting the module (module should be compiled against the kernel version on which it is inserted). Go through stackoverflow link What will happen if two kernel module export same symbol. Hope it answers your question :-).
I searched but didn't see this exact issue answered. We have code (I am building it, not writing it) that fails to compile intermittently due to ambiguous symbol errors. This code produces *.tlb files which evidently contain identical symbols. The developer claims that his code is not the cause of this, but it is the MS build tool. He wants us to reboot when this error occurs. I would think he could change something in the code to alleviate this problem. Can anyone give me some guidance about this? And if it can be fixed in the code, how would it get done, please?
Compiling...
Err_ProjFile: \websvc\AdminWebService\TestNsEndpointInteropClient\TestNsEndpointInteropClient.vcxproj
Err_SrcFile: TestNsEndpointInteropClient.cpp
Err_LineNum: 31 col: 0
Err_Target: ClCompile
Err_Message: C2872: 'EndpointTypeEnum_CenterCord' : ambiguous symbol
Below are the files that reference the tlb files.
websvc
common\lib-proprietary\Aspect.UnifiedIP.Notifications.EndpointClient.tlb
websvc\AdminWebService\AdminWebService.sln
websvc\AdminWebService\TestNsEndpointInteropClient\TestNsEndpointInteropClient.vcxproj
websvc\AdminWebService\TestNsEndpointInteropClient\Aspect.UnifiedIP.Notifications.Common.tlb
websvc\NotificationServer\NotificationServer.sln
websvc\NotificationServer\NsCommon\NsCommon.csproj
I currently run into a problem after I updated my xcode to 4.6.
At the beginning, I got lots of linking errors. With the help from other posts, I am be able to solve them. However, new problems always come whenever I solved the previous one.
Right now, I am stuck at "Undefined symbols for architecture armv7" when I try to build the game on devices with release mode (release and debug modes work for simulator, and debug mode works for devices). I have already researched this problem online, but none of the solutions could solve my situation. That's why I want to start a new post.
Let me explain the situation in details:
All the errors are happened at calling methods in libraries.
my libraries works fine with architecture armv7 before (xcode 4.5)
The current value for Architectures in project file is "Standard (armv7, armv7s)
The current value for Current Architecture is "armv7 armv7s armv6"
This is a sample error:
Even though I only showed errors related to libReceiptVerification.multi.a, errors actually happen at other libraries.
//************* From this line **************
Undefined symbols for architecture armv7:
"_OBJC_CLASS_$_NSMutableOrderedSet", referenced from:
objc-class-ref in libarclite_iphoneos.a(arclite.o)
"_CFStringCreateWithBytes", referenced from:
-[JKSerializer serializeObject:options:encodeOption:block:delegate:selector:error:] in libReceiptVerification.multi.a(JSONKit.o)
_jk_cachedObjects in libReceiptVerification.multi.a(JSONKit.o)
"_CFStringCreateWithBytesNoCopy", referenced from:
-[JKSerializer serializeObject:options:encodeOption:block:delegate:selector:error:] in libReceiptVerification.multi.a(JSONKit.o)
"_CFDataSetLength", referenced from:
__NSStringObjectFromJSONString in libReceiptVerification.multi.a(JSONKit.o)
// *************** Ending Here ***********
So, does anyone has any clue on this problem?
Thanks for your help in advance.
I am having the same problem Solved by setting
Implicitly link Objective-C Runtime Support to NO
You can find it under Project->Build Settings->Apple LLVM Compiler 4.2-Language.
Or search for Implicitly link Objective-C Runtime Support in project->Build Settings
Check out the library targets for libarclite, JSONKit and everything else and make sure they also have the identical architecture values set for their Release builds.
Also that "Build Active Architecture Only" is checked to NO for Release targets.
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*).