I have created my own recipe for building my SW, which requires native perl during building (e.g. invoking perl script for generating code). There is no problem if I add my recipe to an image and use bitbake to build my recipe with the image.
Now I also want to build SW with a populate SDK, but I found that when I generate the populate SDK, the native perl only contains a few modules without what is necessary to build my SW. I have found two ways to generate the populate SDK with additional perl modules:
Add TOOLCHAIN_HOST_TASK += "nativesdk-perl-modules" to my image .bb file before I generate the populate SDK
Add a bbappend file for nativesdk-packagegroup-sdk-host which includes "nativesdk-perl-modules" in RDEPENDS
For 1, it is an image-specific solution.
For 2, it is a global solution.
Now I am looking for a recipe-specific solution. Is there a solution where I could add some configuration in my recipe .bb file, and then I build populate SDK for any image which include my recipe will contains these additional native perl modules?
I'm afraid there isn't really a way for a specific recipe to hint at adding specific dependencies to an SDK. The closest thing I can think of would be to code something into anonymous python in something like an extra global class, where it checks the included target packages and then adds dependencies to TOOLCHAIN_HOST_TASK if the right target packages are being installed. Even this wouldn't detect non direct dependencies of your specific recipe.
Related
Swift Pacakage Manager allows a package manifest (Package.swift) file to specify build settings for targets.
As a security measure, some build settings can only be specified using "unsafeFlags" parameter. For example, specifying a framework search path outside the current directory using the -F build flag is considered "unsafe" because it could lead to code execution outside the package's own directory.
For packages downloaded from the internet, this could be considered an undesirable behavior. However, for locally-declared packages, this could be what we want to do.
However the design of SPM is such that any package that uses "unsafeFlags" cannot be depended on by another package.
Is there any override for this, for example, if we want to use unsafeFlags somewhere in a dependency structure of various locally-declared Swift packages?
Like, is there a setting we can supply for a package, framework, or app, so that it's allowed to depend on packages that use "unsafeFlags"?
Swift Package Manager allows unsafeOptions for dependencies specified by a commit hash. They're not allowed for versioned dependencies.
Example here.
I have a project that is mostly complete for a custom third party SoM which requires custom bootstrap/bootloaders, currently the recipe is in a meta-bsp layer which works alright however they are built in the aarch64-poky-linux build directory. We have multiple SoM models from this manufacturer that each require different bootloader configs and I'd like them to be built in a machine specific non-linux directory if possible like aarch64-<machine>-none or something. Is this possible?
We are using dunfell release.
Recipes are in meta-mfg/recipes-bsp/mfg-/mfg-_version.bb
Fairly standard recipe setup including:
SECTION = "bootloaders"
SRC_URI..
DEPENDS (native packages only)
do_configure()
do_compile()
do_install()
Current build directory: tmp/work/aarch64-poky-linux/mfg-bootloader/1.x.x-rx/
Preferred build directory: tmp/work/aarch64-<machine>-none/mfg-bootloader/1.x.x-rx/
When building for different machines/soms it uses the same directory and uses the previous build which may be incorrect. We do have a workaround where we don't stamp the configure/build/install tasks so they always rebuild however we'd like a cleaner more appropriate implementation.
Is there any way to accomplish this?
I haven't been able to find any information so far.
I have been pointed to the solution from the IRC channel for anyone with the same question:
Add PACKAGE_ARCH = "${MACHINE_ARCH}" to the recipe to build in machine specific folders.
For an application I am running, there is a run time error as it cannot find libwayland-client.so.0 shared object. How do I know which package provides it and where do I add it. I tried as shown below but it gave me a Nothing PROVIDES error.
CORE_IMAGE_EXTRA_INSTALL += "libwayland-client"
You don't typically work with single files when building Yocto images
In reverse order
You install packages to the image
You build packages by using a recipe
You find (or as a last resort write) recipes as part of layers.
Generally when something is missing you take the following steps:
Check the layerindex https://layers.openembedded.org/layerindex/branch/master/recipes/?q=wayland It tells you that there is a recipe called wayland in layer openembedded-core
Add the layer in question. openembedded-core is already contained in Yocto's poky (directly under the name meta, just to confuse the newcomer...), so nothing to add in this example
Create the environment listing of the recipe in question, bitbake -e wayland >wayland.env
Check what packages the recipe in question creates grep ^PACKAGES= wayland.env. In this case it is easy because there is really only one package wayland (-debug, -dev etc. are special purpose that would not contain the library)
Add a package to the image by its package name. How to do that exactly depends on the image type you create. The variable name given in the question works for some images, but not all. Search for IMAGE_INSTALL in the manual https://www.yoctoproject.org/docs/2.6.1/mega-manual/mega-manual.html for other options.
Once you have built the recipe in question you can also check what files are contained in a package (In this case recipe name and package name are identical, but that is not always the case. Some recipes build more than one package suitable for installation, so obviously they need to use different names)
$ oe-pkgdata-util list-pkg-files wayland
wayland:
/usr/lib/libwayland-client.so.0
/usr/lib/libwayland-client.so.0.3.0
/usr/lib/libwayland-cursor.so.0
/usr/lib/libwayland-cursor.so.0.0.0
/usr/lib/libwayland-server.so.0
/usr/lib/libwayland-server.so.0.1.0
I get it that Yocto eSDK is snapshot of pre-configured OpenEmbedded build system. But I want to verify that the custom library that I add as a new meta layer (say, meta-foo layer) becomes a part of eSDK. So, that the user applications may include the header files of this custom library, link against the *.a of this custom library and that the user applications may link in runtime against shared objects of this custom library.
So, is it enough to define in the recipe of this custom library just:
RPROVIDES = "custom_lib1.so custom_lib2.so ..."
... to tell bitbake to copy those *.so libraries to the RootFS?
And how to ensure that the header files of this custom library are copied to the appropriate place, say, /usr/include?
Not exactly, RPROVIDES is used for deliver package dependency, thus You need provide here recipe name.
Firstly You need to create recipe with will use do_install function into deliver needed binaries to ${D}${includedir}/. Then add created package (recipe) as RDEPENDS to nativesdk-packagegroup-sdk-host.bb recipe.
When I run my Unity app in the editor, it is able to read my .dlls and other custom files the .dlls need and it works fine. However, when I make a build, it only includes the .dll files in the Plugins folder of the build and not the other custom files. Is there a way to force Unity to include the other files as well? I have tried putting them both in the Plugins and Resources folder before building and in both cases it only keeps the .dlls.
The custom files are .obf, but I don't think that's relevant
It is extremely relevant. Unity does not support all type of libraries.
Here are the supported library extensions:
For Windows, you can use .dll.
For Linux, .so is supported.
For Android, you can only use .aar, rar and .so.
For iOS, .a is used but you can also use the non compiled code such as ,.m,.mm,.c and .cpp.
There is no support for .obf. If you want to add it to your project so that you can load and execute it then you are out of luck.
If you just want to make Unity include it to your final project build so that you can read it then you can. This doesn't mean you can load and execute it.
First, rename the extension from ".obf" to ".bytes". Place it in the Resources folder and read it as TextAsset with the Resources.Load function. You can the access the data with TextAsset.bytes.
TextAsset dataAsset = (TextAsset)Resources.Load("YourObfName", typeof(TextAsset));
byte[] data = dataAsset.bytes;
Not sure how helpful just reading it is but this is here to show you how to include it to the build and read it but you can't execute it unless there is a C# API to do so and I don't think that any API of such kind exist.