I have downloaded tegra kernel source for Nexus 7 (grouper).
I have added a driver module in drivers/bluetooth/
I have updated the make file and Kconfig file in drivers/bluetooth/
Added the following flags to tegra3_android_defconfig
CONFIG_MODULES=y
CONFIG_MODULE_FORCE_LOAD=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_BT_MYMODULE=m
But when i issue the command
make tegra3_android_defconfig
I find CONFIG_BT_MYMODULE=y in .config file.
Note: The driver module which i have developed does not have dependency on any other kernel modules.
Related
I'm building a Spring Boot (3 RC1) application with some Python code (GraalVM 22.3). Running the application in dev mode works. After building Jar with Maven I get an error:
Caused by: org.graalvm.polyglot.PolyglotException: ModuleNotFoundError: No module named 'pystac'
at org.graalvm.sdk/org.graalvm.polyglot.Context.eval(Context.java:399) ~[org.graalvm.sdk:na]
at ch.so.agi.sodata.stac.ConfigService.readXml(ConfigService.java:116) ~[classes!/:0.0.1-SNAPSHOT]
at ch.so.agi.sodata.stac.SodataStacApplication.lambda$init$0(SodataStacApplication.java:60) ~[classes!/:0.0.1-SNAPSHOT]
at org.springframework.boot.SpringApplication.callRunner(SpringApplication.java:767) ~[spring-boot-3.0.0-RC1.jar!/:3.0.0-RC1]
... 13 common frames omitted
The python.Executable shows to the graalpy executable packaged in the Jar: file:/Users/stefan/sources/datenbezug/sodata-stac/target/sodata-stac-0.0.1-SNAPSHOT.jar!/BOOT-INF/classes!/venv/bin/graalpy
Grepping the Jar shows the pystac module in the Jar file, e.g. BOOT-INF/classes/venv/lib/python3.8/site-packages/pystac/item.py
Creating the context with:
var VENV_EXECUTABLE = ConfigService.class.getClassLoader()
.getResource(Paths.get("venv", "bin", "graalpy").toString())
.getPath();
var context = Context.newBuilder("python")
.allowAllAccess(true)
.option("python.Executable", VENV_EXECUTABLE)
.option("python.ForceImportSite", "true")
.build()
Is it possible to put the whole python stuff including third party libs into the FatJar? Or did I just miss some packaging magic?
The issue is that the default Truffle filesystem, AFAIK, only supports the actual filesystem of your OS, i.e., it does not "see" resources in the jar file. This is why it works in dev mode when the resources are just files on the filesystem.
There are two options how to deal with this:
do not put the venv into resources, but deploy it separately, such that it ends up somewhere on the filesystem
implement custom Truffle filesystem, but I am not aware of anyone who tried this with virtual environments yet, so there may be some rough edges. Most notably GraalVM LLVM Toolchain that is used to build Python native extensions for execution with GraalVM LLVM engine produces system specific binaries, so your jar will not be as portable as one would expect from a jar. If you only use pure Python packages, it may be fine.
I am working on an Android app that is using a c++ shared library. Originally, the project works fine. I recently upgrade the Android Studio to version 4.0.1. I also updated my Gradle version to 4.x but after the update, I have strange problems, so the Gradle version is changed back to 3.6.3.
When the code runs to the statement
try{
System.loadLibrary("something");
} catch(Exception e) {...}
The application throws an exception
java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "_ZN3Eld12PtrModelRefsEv" referenced by "/data/app/com.myapp-aXvdrU70cJvaDOn1c13zEQ==/lib/arm/libsomething.so"...
In the apk file, I can see the library binary file is located in
apk/debug/app-armeabi-v7a-debug.apk/lib/armeabi-v7a/libsomething.so
It seems the app is trying to load the shared library from lib/arm instead of lib/armeabi-v7a
Under the folder something, I have the file build.gradle configs like:
android {
defaultConfig{
ndk {
abiFilters "armeabi-v7a"
}
}
}
Using the readelf -A libsomething.so to check my library file attribute. I have the following result
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "ARM v7"
Tag_CPU_arch: v7
Tag_CPU_arch_profile: Application
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-2
Tag_FP_arch: VFPv3
Tag_Advanced_SIMD_arch: NEONv1
Tag_ABI_PCS_GOT_use: GOT-indirect
Tag_ABI_PCS_wchar_t: 4
Tag_ABI_FP_denormal: Needed
Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align_needed: 8-byte
Tag_ABI_enum_size: int
Tag_CPU_unaligned_access: v6
Tag_ABI_FP_16bit_format: IEEE 754
I tried to use System.setProperty("java.library.path", "lib/armeabi-v7a"); to change the library loading path. But it does not change anything.
So, how can I let the function System.loadLibrary loading the binary library file from the correct location?
Android Studio version: 4.0.1
Android Gradle Plugin Version: 3.6.3
Gradle Version:6.3
I finally found that I forgot to add a CPP file to the make file. _ZN3Eld12PtrModelRefsEv is a mangled function name of PtrModelRefs which is the most important info I missed. Basically it is saying undefined function.
Using libgdx 1.7.0/Android Studio, TexturePacker is supposed to be included out of the box if checking the tools option when creating the project (and so I did).
In fact, if I check my build.gradle file, in the project(":desktop") section I have the compile "com.badlogicgames.gdx:gdx-tools:$gdxVersion" added.
But even with that, the build is not able to find the tools package (even though I can successfully use the Controllers extension, which should be the same I think)
I'll leave here the desktop part of the build.gradle, just in case:
project(":desktop") {
apply plugin: "java"
dependencies {
compile project(":core")
compile "com.badlogicgames.gdx:gdx-backend-lwjgl:$gdxVersion"
compile "com.badlogicgames.gdx:gdx-platform:$gdxVersion:natives-desktop"
compile "com.badlogicgames.gdx:gdx-box2d-platform:$gdxVersion:natives-desktop"
compile "com.badlogicgames.gdx:gdx-controllers-desktop:$gdxVersion"
compile "com.badlogicgames.gdx:gdx-controllers-platform:$gdxVersion:natives-desktop"
compile "com.badlogicgames.gdx:gdx-freetype-platform:$gdxVersion:natives-desktop"
compile "com.badlogicgames.gdx:gdx-tools:$gdxVersion"
}
}
And a image with the libraries in the project, where you can see the tools...
This is an issue caused by importing tools in Core Dependency. Remove the dependency in the project(":desktop") of the Core Dependency and add it to desktop dependency.
You can also solve it by downloading the gdx tools and importing the jar file. Just create a library folders and paste the jar file. Then go to File > Project Structure > Modules and add the File Dependency which is your jar file.
dependencies {
compile files('libs/runnable-texturepacker.jar')
}
This should work fine.
I was trying to use the TexturePacker class within a class in the core module. However I discovered it to only be available in the desktop module.
This seems logical as the dependency of the tools extension is placed within the desktop project in the root build.gradle file when using the setup utility or following the official instructions to add the extension manually (see Add tools dependency).
Technically, you could move the dependency in the module you want to use TexturePacker in (say core), but according to the provided link this is discouraged. So I recommend you just write your class using TexturePacker within the desktop module.
PS: Note that due to the deprecation of "compile" a replacement by "implementation" in build.gradle might become necessary, but Android Studio will inform you in that case (use ctrl + r for efficient replacements).
I couldn't find any information regarding this in kbuild modules documentation and only an oblique reference (suggesting that it's possible) in the headers_install documentation.
The "make headers_install" command can be run in the top level directory of the
kernel source code (or using a standard out-of-tree build).
I have an out-of-tree kernel module with an associated header file (I have #defines for an IOCTL), and I want to provide that header file as part of the module installation. It seems like the in-tree way for kernel modules to provide header files (for userspace use) is to place them in include/linux/. What do I have to do for this to work for out-of-tree?
Ok, this seems to be another case where I didn't read all the manuals... the manual needed is the makefiles documentation for kbuild...
The kernel includes a set of headers that is exported to userspace.
Many headers can be exported as-is but other headers require a
minimal pre-processing before they are ready for user-space.
The pre-processing does:
drop kernel-specific annotations
drop include of compiler.h
drop all sections that are kernel internal (guarded by ifdef KERNEL)
Each relevant directory contains a file name "Kbuild" which specifies the
headers to be exported.
See subsequent chapter for the syntax of the Kbuild file.
--- 7.1 header-y
header-y specifies header files to be exported.
Example:
#include/linux/Kbuild
header-y += usb/
header-y += aio_abi.h
This seems to be deprecated. The headers_install target does not exist for out-of-tree module builds (see this answer).
I'm trying to add ActionbarSherlock as dependency using line I got from gradleplease
(Instead of these methods. At least according to this link:
"In Gradle you no longer need to add in these libraries as source code projects; you can simply refer to them as dependencies, and the build system will handle the rest; downloading, merging in resources and manifest entries, etc. For each library, look up the corresponding AAR library dependency name (provided the library in question has been updated as a android library artifact), and add these to the dependency section."
this setup should not be necessary anymore)
But it doesn't work and module settings in Android studio shows error: "Library 'ComActionbarsherlockComActionbarsherlock440.aar': Invalid classes root"
Any idea?
Add these line in your module build.gradle
dependencies {
compile 'com.actionbarsherlock:actionbarsherlock:4.4.0#aar'
}