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.
Related
Hello i have a problem when i build a program.
I simply type 'make' but i get a lot of errors from headers files.
Like unknown variable types.
For example:
'size_t' undeclared did you mean 'ssize_t' ?
unknown type name '__gnuc_va_list' did you mean '_IO_va_list'?
I tried to reinstall linux headers, I changed variable types (i know is better not to change system files), included header files but nothing
My laptop has been built with ubuntu, maybe i missed some steps after the installation?
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.
I am using Buildroot to create Rootfs for embedded system
When trying to build QT, I get this build error:
`compiling egl/qegl_qws.cpp
egl/qegl_qws.cpp:1:0: warning: switch -mcpu=cortex-a15 conflicts with -march=armv7-a switch [enabled by default]
/****************************************************************************
^
moc embedded/qsoundqss_qws.h
moc embedded/qcopchannel_qws.h
moc embedded/qdecorationplugin_qws.h
moc embedded/qdirectpainter_qws.h
moc embedded/qwsmanager_qws.h
In file included from /home/hamzah/buildroot/output/host/usr/arm-buildroot-linux-gnueabihf/sysroot/usr/include/X11/Xlib.h:44:0,
from /home/hamzah/buildroot/output/host/usr/arm-buildroot-linux-gnueabihf/sysroot/usr/include/EGL/eglplatform.h:118,
from /home/hamzah/buildroot/output/host/usr/arm-buildroot-linux-gnueabihf/sysroot/usr/include/EGL/egl.h:36,
from egl/qegl_p.h:66,
from egl/qegl_qws.cpp:46:
../../include/QtCore/../../src/corelib/kernel/qcoreevent.h:70:9: error: expected identifier before numeric constant
None = 0, // invalid event
^
../../include/QtCore/../../src/corelib/kernel/qcoreevent.h:70:9: error: expected '}' before numeric constant
../../include/QtCore/../../src/corelib/kernel/qcoreevent.h:70:9: error: expected unqualified-id before numeric constant`
This is because None is #defined to be 0 in X11 headers which is creating confllict when used as enum member. From internet, I have been advised to put X11 headers AFTER QT headers. I have tried it where I could find but it does not solve the problem. I think I missed some files
I tried to #undef the symbol and #define laters but that produced more errors as expected. Has anyone dealt with this before and could tell me the exact place to make a change, or do I have to go through a crazy amount of files myself to make changes?
Also, if you have any tip to make this task easy, kindly share. I would even love to know name of all X11 header files
Please report your bug to the Buildroot community, either by posting an e-mail to the mailing list, or filing a bug in the project bug tracker. In either case, make sure you include the Buildroot version, as well as your complete Buildroot .config file to reproduce the issue.
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*).
I am trying to build an old version of an application which consists of VC++ projects that were written in Visual Studio 2003.
My OS is Windows 7 Enterprise (64-bit).
When I try and build the solution I get the following errors:
error C4772: #import referenced a type from a missing type library; '__missing_type__' used as a placeholder
fatal error C1084: Cannot read type library file: 'Smegui.tlb': Error loading type library/DLL.
They both complain about the following import statement:
#import "Smegui.tlb" no_implementation
This is not a case of the file path being incorrect as renaming the Smegui.tlb file causes the compiler to throw another error saying it cannot find the library.
Smegui is from another application that this one depends on. I thought perhaps I was missing a dll but there is no such thing as Smegui.dll.
All I know about .tlb files is that they are a type library and you can create them from an assembly using tlbexp.exe or regasm.exe (the later also registers the assembly with COM)
There is also an Apache Ant build script which uses a custom task to invoke devenv.com to build the projects. This is the same script that the build server originally used to build the application. It gives me the same errors when I try and run it.
The strangest thing about this is that I knew it ought to work seeing as it is all freshly checked out from subversion. I tried many different combinations of admin vs user elevation, VS vs Ant build, cleaning, release.
I have got it to build successfully about 5 times but the build seems to be non-deterministic.
If anyone can shed some light on how this tlb stuff even works or what this error might mean I would greatly appreciate it.
I found a far more reliable solution: open the tlb with oleview.exe and then close it.
Not sure what this actually does but it works every time.
I think oleview is actually one of the samples included with Visual Studio but I haven't had the time to debug it and see what it is doing.
I ran into this error because one type library was trying to load a dependent type library, which it could not find. Even though the dependent type library was in the same directory, and even though that directory was in the searchable path, the compiler would error loading the first type library, but not mention the dependent type library in the error.
To find the pseudo-missing type library, I ran Process Monitor (procman64.exe) during the compile. This showed that after the reported type library had successfully loaded, a dependent type library could not be found. It even showed all of the places that it was looking for the dependent type library, none of which were where it should have been looking (e.g.: ).
The fix was to add a <PreBuildEvent> to the project to copy the dependent .tlb file to one of the directories that was actually being searched.
<PreBuildEvent>
<Command>copy /Y ..\Lib\Interop\CWSpeechRecLib.tlb .\</Command>
</PreBuildEvent>
http://msdn.microsoft.com/en-us/library/sce74ah7%28VS.71%29.aspx
smegui.tlb is referencing some other tlb that the compiler can't find. If you have the .idl for smegui you might be able to figure out what the other is. I suspect the missing tlb is something that original build machine had registered but that your machine doesn't have registered.
A type library is a binary description of a set of interfaces, coclasses and enums. They're usually generated for COM components, in the case of tlbexp and regasm the tlb is created from the assembly metadata. For native COM components they are usually generated from an idl (Interface Description Language) file by the midl tool.
Edit:
I just noticed you're on x64 Windows. Are you building the project with a new version of Visual Studio? If so, are you targeting x86 or x64? If the latter, it may simply be a 32bit component that the compiler can't find (or less likely, a x64 component the x86 compiler can't find if you are targeting x86), for WOW64 the registry is virtualized for x86 vs. x64 applications.
Well I finally found out why I managed to get it to build sometimes and not others... sort of.
So long as I ran the build script with elevated administrator permissions and let that get as far as it could until that error occurred, then run the build script again as a protected administrator succeeded. Those steps must be done in that exact order with no other steps in between. If I try build in Visual Studio it does not work (although I did get it to succeed once). Probably some kind of virtualisation issue although it still doesn't quite make sense.
Well I don't need help on this any more and I know it's probably impossible to fully answer this question without knowing exactly what the build is doing. However if anyone does have any more thoughts I would happily receive them.
Cheers,
Steiny