I have a working Linux system image being produced for my ARM board with Yocto ( Dunfell branch ).
Space occupied by the rootfs is a premium and I am working on shrinking the image.
I want to experiment with the GCC '-Os' flag, to optimize for space. I would like to set this globally for my experiment. I found the following information in a presentation ( https://pretalx.com/yocto-project-summit-2020/talk/AY37HF/ ):
I added the following to my image_0.1.bb file. However, I do not see the '-Os' optimization flag being used in any package.
# Disabled until the option works properly -feliminate-dwarf2-dups
FULL_OPTIMIZATION = "-Os -pipe ${DEBUG_FLAGS}"
DEBUG_OPTIMIZATION = "-Og ${DEBUG_FLAGS} -pipe"
SELECTED_OPTIMIZATION = "${#d.getVar(oe.utils.vartrue('DEBUG_BUILD', 'DEBUG_OPTIMIZATION', 'FULL_OPTIMIZATION', d))}"
Is the code correct and, if so, where should I put this code? If not correct, how can I globally add the '-Os' compiler optimization flag to my project?
Global options must be added to one of the global configuration files.
For testing things this would typically be conf/local.conf.
You only need to add the variables you actually change as bitbake uses lazy evaluation of variables values.
Variables in recipe files only affect the tasks for that recipe. This means that nothing you do in the image recipe can affect how tasks in other recipes are done.
Related
I maintain a custom Yocto meta layer compatible with Dunfell. It supports a Microchip SAMA5D27 processor based board. I have several bbappend files in this layer that apply only to file from the meta-atmel and other Microchip specific packages.
Now, I want to re-use many parts of this custom meta layer and support a new processor from a different vendor. I have created my own new image recipe in my layer that does not include these bbappend files that are only relevant to Microchip.
The problem is that Yocto throws as error 'No recipes available for' regarding my bbappend files. The error seems to happen during parsing and does not consider whether I use the recipe or not in the current target.
I have searched extensively for a solution, but so far have come up empty. How can I use 1 meta-layer and maintain different bbappend files, while being able to switch MACHINE variables for different target builds?
Bitbake Version:
root#buildmachine:/$ bitbake --version
BitBake Build Tool Core version 1.46.0
I have tried to use the COMPATIBLE_HOST and COMPATIBLE_MACHINE variables in these bbappend files, but the error remains.
# Only compatible with sama5d27 microchip
COMPATIBLE_HOST = "arm-poky-linux-musleabi"
COMPATIBLE_MACHINE = "sama5d27-wlsom1-ek-sd"
Error output:
root#buildmachine:~/Desktop/compulab/build-cmdline$ MACHINE=iot-gate-imx8 bitbake iot-gate-imx8-image
WARNING: Host distribution "ubuntu-20.04" has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution.
Loading cache: 100% |#######################################################################################################################################################| Time: 0:00:01
Loaded 4938 entries from dependency cache.
ERROR: No recipes available for:
/home/me/Desktop/compulab/sources/meta-proprietary/recipes-bsp/at91bootstrap/at91bootstrap_3.10.0.bbappend
/home/me/Desktop/compulab/sources/meta-proprietary/recipes-bsp/dt-overlay-at91/dt-overlay-at91_git.bbappend
/home/me/Desktop/compulab/sources/meta-proprietary/recipes-bsp/libubootenv/libubootenv_%.bbappend
/home/me/Desktop/compulab/sources/meta-proprietary/recipes-bsp/u-boot/u-boot-at91_2020.01.bbappend
/home/me/Desktop/compulab/sources/meta-proprietary/recipes-core/initrdscripts/initramfs-debug_%.bbappend
/home/me/Desktop/compulab/sources/meta-proprietary/recipes-httpd/nginx/nginx_%.bbappend
/home/me/Desktop/compulab/sources/meta-proprietary/recipes-kernel/linux/linux-at91_5.4.bbappend
The issue as you've discovered is that Yocto is unable to match the .bbappend files to any recipes when you switch to another MACHINE.
You can solve the problem by conditionally including your .bbappend files only if particular layers are enabled. Yocto supports this through the BBFILE_DYNAMIC variable.
For instance, if you keep your .bbappend files in the dynamic-layers/meta-atmel folder within your own layer, and you only want to include those .bbappend files if meta-atmel is in use, then add the following to your layer.conf:
BBFILES_DYNAMIC += "\
meta-atmel:${LAYERDIR}/dynamic-layers/meta-atmel/recipes-*/*/*.bbappend \
meta-atmel:${LAYERDIR}/dynamic-layers/meta-atmel/recipes-*/*/*/*.bbappend \
"
(adjust paths / folder depth as appropriate).
This says that if meta-atmel is included in the list of layers, then add the two dynamic-layers/... paths to the search path.
You cannot append to a recipe that does not exist in the first place.
If the recipes exist:
at91bootstrap_3.10.0.bb
dt-overlay-at91_git.bb
...
make sure that their layer is added to bblayers.conf.
According to various guides on cross-compiling Rust I need to set something like this in .cargo/config:
[target.x86_64-unknown-linux-musl]
linker = "x86_64-linux-musl-gcc"
In my case I am cross compiling for Linux on Mac. This is fine, but I'd also like to be able to build the code natively on Linux (i.e. not cross-compiling). In that case surely the target is still x86_64-unknown-linux-musl, but I don't want to override linker then.
I guess you can probably do this using a custom build.rs, but is there any way to do this from .cargo/config? I thought you'd be able to do something like this:
[target.'cfg(all(host_os = "macos", target_os = "linux"))']
linker = "x86_64-linux-musl-gcc"
But there is no host_os.
I'm guessing that you've put .cargo/config inside of your Cargo workspace?
If this the case, you should consider moving host-specific configuration options (such as target.{target}.linker) into your user-specific ~/.cargo/config instead. That way, the linker is not tied to the workspace configuration, but instead to the user: different users on different hosts could have different linkers configured for different targets.
I have a project build by scons.
In the project there are multiple components, including client, shell, engine and etc...
Each component uses different compile options so they are split into different env.
And both shell and engine are going to require client libraries built first.
In the environment settings, both shell and engine has something like "-lclient -L[installpath]/lib", and SConscriptClient is going to build the libclient.a in [installpath]/lib.
So I expect SConscriptClient is run before everything else.
so in the code I have something like:
clientbuild = clientEnv.SConscript ( 'SConscriptClient', variant_dir=clientDir )
if hasShell:
shellbuild = shellEnv.SConscript ( 'SConscriptShell', variant_dir=shellDir )
Depends ( shellbuild, clientbuild )
if hasEngine:
enginebuild = engineEnv.SConscript ( 'SConscriptEngine', variant_dir=engineDir )
Depends ( enginebuild, clientbuild )
However it seems scons is not smart enough to understand the dependencies between client/shell and engine ( that means the Depends call doesn't take effect ). It still try to run SConscriptShell before SConscriptClient
Is there anything i can do to set the dependeices between sconscript?
You shouldn't have to explicitly set these dependencies with Depends(). If the client library is a target built by SCons and both the shell and engine link that library, then SCons should be able to implicitly determine the dependencies and build the client first.
Basically, I see 2 issues here:
Why doesn't SCons implicitly figure out the dependencies?
Why isn't it working as is with the explicit calls to Depends()?
If we figure out number 1, then we wont have to figure out number 2. But just to be complete, I think number 2 isnt working because of what the call to SConscript() is returning. In the subsidiary SConscript scripts (SConscriptClient, SConscriptShell, and SConscriptEngine) are you returning the target? If not, I would imagine the clientbuild variable would be None. To return the target use the Return() SCons function and pass it the return value of the Library() builder.
As for why SCons cant figure out the dependencies implicitly, we would need to see the subsidiary SConscript build scripts. But I can imagine its because you are probably specifying the client library "by hand", so SCons doesnt see the dependency.
The way to build a program with a library so that SCons can see the dependency, you need to use the LIBS construction variable, as follows:
env.Append(LIBS='client')
env.Append(LIBPATH='path/to/client/lib')
env.Program(target='shell', source='shell.cc')
Notice I don't use the -l nor the -L flags above, SCons will add those in a platform independent manner. If you're specifying the library "by hand" by specifying it like this: '-lclient' then SCons wont see the dependency. This is by design, and is more interesting with include paths: if you have a lot of include paths with header files that will almost never change, then (for performance reasons) you don't want SCons to scan them for changes, and thus specify them "by hand".
One additional comment, normally the different environments are passed to the subsidiary SConscript build scripts differently, as follows:
clientEnv = Environment()
# set the clientEnv accordingly
SConscript ('SConscriptClient', variant_dir=clientDir, exports=['clientEnv'] )
SConscriptClient:
Import('clientEnv')
# You may want to clone the clientEnv here, if you want to make
# changes that you don't want seen in the rest of the build
We using an automated build system which downloads and compiles source. The only interface I have to control the behaviour of the compilation is by setting ENV VARs and the arguments given to `./configure'.
The issue is that the 'configure' script (of the particular source I'm compiling) checks for a system header file, which if found, adversely affects the compilation process. (the compilation process will avoid compiling libraries which it believes are already installed on the local system when the above mentioned system header file is found.)
Since this is an automated process, I cannot modify the 'configure' script in anyway, and as mentioned can only specify the environment variables and arguments passed to `configure'. The configure script uses the AC_CHECK_HEADERS macro to generate the code to do the check for the system file. Is there anyway to avoid a check of a specific system file from the configure arguments?
The troublesome header file is in the path /usr/include/pcap/.
Thanks
Well there's a few things you could try:
remove foo.h from AC_CHECK_HEADERS and always build the library
use AC_CHECK_HEADER for foo.h and check for /usr/include/pcap/foo.h and don't AC_DEFINE(HAVE_FOO_H) if /usr/include/pcap/foo.h is there.
you could use AC_ARG_ENABLE or AC_ARG_WITH to turn off the offending test on a host-by-host basis via arguments to configure. So the answer to that question is yes.
All of these assume you can modify configure.ac and regenerate configure. If you can't do that you might have to modify configure (in an automated fashion, of course).
I'm new to platform builder, this might be obvious..
I'm working on wince6.0.
I've looked everywhere, didn't find how to add flags to the compilation of the image.
I've noticed there are many flags which are specific to ARM:
http://207.46.16.248/en-us/library/ee479941%28WinEmbedded.60%29.aspx
/QRArch
/QRimplicit-import-
/QRinterwork-return
/QRxscale
/QRxscalesched
/QRthumb
How do I add them to the build and which ones take parameters (and what are they)?
Are there any general flags too? what are they?
Thank you
Apparently, you need to do two things:
Go to project properties
Add environment variable named "cl" with value such as the following or a subset of them:
/QRArch
/QRimplicit-import-
/QRinterwork-return
/QRxscale
/QRxscalesched
/QRthumb
Afterwards, you edit the sources.cmn located in the BSP folder, adding:
CDEFINES=$(CDEFINES) <the flags you picked above>
For example if I wanted to use /QRArch4 and /QRimplicit-import-
The cl variable value would be /QRArch4 /QRimplicit-import-
and the line added to the sources is:
CDEFINES=$(CDEFINES) /QRArch4 /QRimplicit-import-