<richard.purdie@...> wrote: This is manually fixing the misconversion of _ESCAPED to :ESCAPED, right? If so then does it mean a bug in the automatic conversion script since overrides c

<richard.purdie@...> wrote: There's no need to move the recipe, just adding to oe-core should be enough.

<dwrobel@...> wrote: Comments say DISTRO_FEATURES but code is checking IMAGE_FEATURES in both cases. ldconfig is a distro feature and read-only-rootfs is an image feature, so both the c

<dwrobel@...> wrote: Of course. But if ldconfig support is disabled at build time (ie the ldconfig distro feature is disabled) and there is no package management support (so ldconfig ca

<dwrobel@...> wrote: Should there be a test for package management being supported in the image too? A read-only rootfs is one case where it's not possible to install ldconfig support a

Why is an interesting side discussion. Getting back to the original question though, either OE officially supports creating unstripped binaries or it doesn't. The documentation should perhaps be updat

<alex.kanavin@...> wrote: The typical ordering of variables etc in recipes is to put SRC_URI before inherit. From the perspective of trying to get recipes to stick to a standard ordering of vari

Have you built the recipe for two different machines in the same build directory? If you completely remove tmp and then build again for a single machine you should see only one WORKDIR created (which

Subject mentions mips, not powerpc.

The SIMD code can only be used on targets which support neon. There may be other cases where the code can be compiled but if it can never be used at run time it's not very useful.

Drop this comment. Neon may be missing from other ISA levels too (i.e. this fix is not specific to armv5). Shouldn't this be checking for neon in TUNE_FEATURES rather than TUNE_CCARGS_MFPU? It should

Just a warning, but if your Makefiles are not generating versioned shared libraries then they are probably not setting a soname either... and that really messes up OE's automatic runtime dependency tr

<richard.purdie@...> wrote: Could we perhaps have an "official" recommendation on that somewhere which users etc could be pointed to? I've just had a discussion along the lines of "but

Did that actually help with the image size? Yes, if you remove debug symbols before packaging then they won't be available to put in the -dbg packages. Isn't that what happens by default? This came up

As much as I'd like to see mklibs fully supported in OE, at some point maybe we should just admit that it doesn't work and there's not enough collective motivation to fix it. For mklibs to work, the b

This thread seems to have covered the main point already (if you want to save time by not packaging unwanted files then don't install the files in the first place). It's perhaps worth noting one very

Yes, I think so. Creation of the debugfs tar file uses a lot of the same logic as creation of the rootfs image(s) so is controlled by similar variables (e.g. IMAGE_FSTYPES_DEBUGFS is the equivalent of

<alex.kanavin@...> wrote: None of the answers given so far seem very convincing... If the git revision that a recipe wants is available on an unexpected branch in the upstream repo then it's not

Seems like something which should be fixed by a patch to the source code (and submitted upstream).

Didn't we discuss exactly this (ie the difference between a pure SDK recipe such as meta-toolchain and the populate_sdk task of an image recipe) a couple of weeks ago? Both are valid ways to create an