here is the code that i wrote: link
and im selecting the following defconfig(exynos8890-herolte_kor_defconfig) for compiling defconfig file
and my core function (kernel/examplepatch/core.c) is depend on the following options as described in kernel/example/Kconfig
config HAVE_EXAMPLEPATCH
bool
help
Arch supports kernel example patch
config EXAMPLEPATCH
bool "Kernel example patch"
depends on DYNAMIC_FTRACE2
depends on MODULES
depends on SYSFS
depends on KALLSYMS_ALL
depends on HAVE_EXAMPLEPATCH
help
Say Y here if you want to support kernel example patch.
and the following options depends on MODULES , depends on SYSFS and depends on KALLSYMS_ALL are selected through defconfig which i selected at compile time(exynos8890-herolte_kor_defconfig) and the rest dependencies depends on HAVE_EXAMPLEPATCH and depends on DYNAMIC_FTRACE2 are selected through arch/arm64/Kconfig link within CONFIG_ARM64(and exynos8890-herolte_kor_defconfig has CONFIG_ARM64 option too)
but unfortunatly the kernel/examplepatch/core.c refuses to compile i cant see the core.o (compiled object) in kernel/examplepatch
so what part or things are wrong?
thanx
regards
Related
I was checking out Pion Mediadevices and trying to cross-compile the webrtc example for a rasperry pi zero from my windows computer. When I try to build the example though, I get these errors from Windows command prompt:
# github.com/pion/mediadevices/pkg/codec/mmal
..\..\pkg\codec\mmal\params.go:30:9: undefined: newEncoder
# github.com/pion/mediadevices/pkg/driver/microphone
..\..\pkg\driver\microphone\microphone.go:27:10: undefined: malgo.AllocatedContext
..\..\pkg\driver\microphone\microphone.go:34:2: undefined: malgo.DeviceInfo
..\..\pkg\driver\microphone\microphone.go:40:13: undefined: malgo.InitContext
..\..\pkg\driver\microphone\microphone.go:40:36: undefined: malgo.ContextConfig
..\..\pkg\driver\microphone\microphone.go:78:25: undefined: malgo.DeviceInfo
Also because the program is for the pi zero I edited the import section to have "github.com/pion/mediadevices/pkg/codec/mmal" and commented out the x264 import.
What is the correct way to build this example?
Edit: Upon further investigation, I found that the error message above:
..\..\pkg\codec\mmal\params.go:30:9: undefined: newEncoder
correlates to a call to the function newEncoder which is declared in a seperate go file, mmal.go, in the same folder as params.go. Both of these files have package mmal at the top before their imports and the folder they're contained in is also called mmal. Is there any problems there causing the function to not be viewable to params.go?
mediadevices currently uses cgo to give us access to camera/microphone and codecs. Cross-compiling in cgo is possible but you would very likely need to cross-compile mmal codec as a static library yourself, but this requires access to the source code.
Unfortunately, mmal is not an open-source library. Therefore, the only option left is to compile the library on the raspberry pi since mmal should be installed on your system already.
Note: I'm the mediadevices author 😃.
I'm cross compiling on Windows 7 and I use this compiler:
gcc-linaro-arm-linux-gnueabihf-4.7-2013.03\bin\arm-linux-gnueabihf-g++.exe
I want to use libcurl for some HTTP requests but when I link using -libcurl I get the infamous message that the linker couldn't find that library. I tried searching on the internet for the correct library for this architecture (ARMHF) but I can't find anything. Or maybe I did find it but I'm doing things wrong? My linking call is long but here it is:
This is the one that works, if I add -libcurl or anything related it breaks...
C:\vde\toolchains\windows\vos2\gcc-linaro-arm-linux-gnueabihf-4.7-2013.03\bin\arm-linux-gnueabihf-g++.exe -o out\RefApp -Wl,-rpath=C:\vde\SDKs\vos2\vos2-sdk-winx86-release-31010800\vos2\usr\lib -Wl,-r
path=C:\vde\SDKs\vos2\vos2-sdk-winx86-release-31010800\vos2\usr\local\lib -Wl,-rpath=C:\vde\SDKs\vos2\vos2-sdk-winx86-release-31010800\vos2\lib -Wl,-rpath=C:\vde\SDKs\vos2\vos2-sdk-winx86-release-3101
0800\vos2\usr\local\lib\svcmgr C:\desarrollo\corvet\out\corvet.a -LC:\desarrollo\RefApp\lib -LC:\vde\SDKs\vos2\vos2-sdk-winx86-release-31010800\vos2\usr\local\lib -LC:\vde\SDKs\vos2\vos2-sdk-winx86-re
lease-31010800\vos2\lib -LC:\vde\SDKs\vos2\vos2-sdk-winx86-release-31010800\vos2\usr\local\lib\svcmgr -LC:\vde\ADKs\adk-full-4.6.5-610\vos2\lib -L -LC:\desarrollo\corvet\out -lrt -llog -lvfiguiprt -l
vfiipc -lTLV_Util -lpthread -lvfiplatforminfo -lsvc_utility -lvfibuzzer -lsvc_powermngt -lsvc_led -lvfisysinfo -lvfisysbar -lsqlite -lexpat -linf -lcom -levt -ltecclient -lmsrclient -lEMV_CT_Link -lEM
V_CT_Client -lEMV_CTLS_Link -lEMV_CTLS_Client -lNFC_Framework -lNFC_Client -lsvc_tms -lUtils -lseccmd-static -lsvc_sound -lccp -lcrypto -lsec -lseccmd-static -lsecins -lvfisvc -lvfisyspm -lvfimac -lvf
isec -lAdkCapX
I also tried downloading some libcurl libraries I found on debian page and that were supposedly for ARMHF, put them in some folder and used -L(routetofolder) but that didn't work either.
Hope you guys can help me out.
Thanks!
Well, libcurl is there in what you get from the vendor (if you look at /usr/lib you will find it there). It's a problem with your linking.
You might want to try looking at how dynamic libraries dependencies are resolved at linking and later at runtime on linux systems. It will also help you understand what may be happening on vos2 platform when you will try using your own dynamic libraries that may have conflicting names and linker can resolve them to something existing on the same device but at a location that you might not have permissions to read, because it belongs to different usrXX or sysXX.
Reading /etc/ld.so.conf from the device will help you understand the locations and search order done by dynamic linker. You can get the file from the device or simply find it in OS.rfsbundle (look in skeletonfs) and set your linking options right. I think it's not normally distributed with sysroot by the vendor but you can manually add it.
I have successfully taken bio-metric prints and posted to the node server using the futronic sdk. I want to be able to use this library likewise for matching in the server because that's where the bio-metric prints for all users are stored. I stubbled upon the node-ffi library that helps define equivalent C functions that I have exported and compiled it down to a .dll file.
Now the challenge here is that I have tried to port the ftrAnsiSDK functions but the ftrScanAPI.dll and the ftrAnsiSDK.dll file could not be compiled together. It gives this error:
...collect2.exe [Error] ld returned 5 exit status
When I compile and export the functions that are not dependent on these two libraries, my code works fine and the functions are easily exported and used in the node server. Please can any one give me a hint?
Here is the link to the repo. It consists of the lib and .dll library that is been used.
For the server code here is a snippet of what I am trying to achieve:
var libm = ffi.Library('lib/visystem', {
'HelloWorld': [ 'void', [] ],
'PrintErrorMessage': [ 'void', ['int'] ],
'CaprureImage': [ 'int', ['int','int','int'] ]});
The HelloWord and PrintErrorMessages are methods that I used as a test case to ensure the functions are being exported before I proceeded to the main functions (you can see the function definition in from the code in the repo.. ) that depends on the futronic lin and sdk.
I am currently using a 64-bit operation system and I installed the same program on a 32-bit machine to be sure, but it still did not compile and export the function. The code editor I am using is Dev++C.
Can anyone help or even give me hint on how to achieve this goal?
As a disclaimer, I'm not familiar with the Dev-C++ IDE or MinGW development.
However, after a cursory look at your github repo, according to your libvisystem.def file, it appears that the only functions that are exported by your DLL are:
HelloWorld
PrintErrorMessage
ReadTemplateFile
SaveBmpFile
SaveTemplateFile
This is also confirmed when looking at the libvisystem.a library header:
So you should probably start by manually add the rest of the exported functions in your dll.h to the def file, in a similar manner to the ones that are already there, and see if that changes anything.
NOTE:
I'm not sure whether the __declspec(dllexport) directive is ignored by the Dev-C++ compiler/linker and it uses the def file instead. Perhaps others on SO have an idea.
I am trying to make a kernel module loadable on run time. i.e remove it from normal makefile tree compilation, compile it separately and load it via kldload
My configuration:
* I am using freebsd 9.0 stable
* make buildkernel with a standard Makefile
As of now I have no clue how to start with this, googled a bit but no success so far.
So how do I remove my kernel module "module_test" from Makefile and start with separately.
Do i need to change any thing from code also apart from makefiles ?
Any pointers to start of with.
There are several modules in the ports collection. Take a look at their buildsystems.
The portnames usually ends in -kmod; E.g: audio/aureal-kmod, comms/hso-kmod comms/ib-kmod comms/uhso-kmod etc.
I'm trying to adjust 3rd person code to my needs. This code is provided with CMake config files used to build and install it. There is possibility to choose one of libraries. And in code is often used #ifdef USE_FTD2XX directive. I saw that this is defined in CMamkeFiles.txt file like here:
option(USE_FTD2XX "Use FTDI libFTD2XX instead of free libftdi" ON)
if(USE_FTD2XX)
find_package(libFTD2XX)
endif(USE_FTD2XX)
if(LIBFTD2XX_FOUND)
include_directories(${LIBFTD2XX_INCLUDE_DIR})
add_definitions( -DUSE_FTD2XX )
else(LIBFTD2XX_FOUND)
set(LIBFTD2XX_LIBRARIES "")
endif(LIBFTD2XX_FOUND)
But if I simply use *.c and *.cpp files and I analyse and run it simply from IDE (Codeblocks), how could I set using this library in C++ code instead of in CMake? I'm also sure that I want use always this one so it can be fixed.
Should I simply #define USE_FTD2XX in main file?
You cannot simply #define USE_FTD2XX because you also need specific linker options for this to work (i.e. the library to link with). If the option is OFF in cmake, the specific link options won't be present in the Makefile and most likely you'll have linker errors.
So CMake takes care of everything automatically for you, but you need to re-generate your makefiles each time you want to toggle options on/off.
If only headers were involved and no library to link with (like some parts of the Boost framework), then yeah, defining USE_FTD2XX in your should be enough.