CODEWITHSUNDEEP
yoctobitbakeopenembedded
Sam Liddicott
Sam Liddicott

Reputation: 1406

recipe also produces -native output that needs packaging

I have a recipe which successfully invokes a legacy build command to cross-compile a target.

As a side effect it produces some custom native tools that are used in the build.

I want to reap those tools into a -tools-native package to allow other recipes to depend the main package to access the artifacts, and use the -tools-native package to further process those artifacts.

I can build such a native package as simply as adding:

PROVIDES = "${PN} ${PN}-tools-native"
SYSROOT_DIRS += "/"
PACKAGES += "${PN}-tools-native"
FILES_${PN}-tools-native += "/native-bin/*"

and having the install section install the native tools to /native-bin/

but yet it somehow isn't a real native package, and when DEPENDS'd by an additional recipe the native-bin artifacts are installed inrecipe-sysrootinstead ofrecipe-sysroot-native`

I also have to install the tools 0644 or bitbake tries to strip them (and fails, as they are native build).

Because the native tools are already generated by the legacy build commands, I don't need to actually invoke as a -native recipe variant.

It's a long process, I don't want to run it twice, either.

Currently I work around it by having the other recipes DEPEND on recipe-native-tools and fixup the permissions and PATH

But what's the proper way to do this?

Upvotes: 2

Views: 2481

Answers (1)

Richard Purdie
Richard Purdie

Reputation: 2358

This is generally handled by separate recipes. There is no mechanism to share native binaries from target recipes as their task hashes have the wrong kinds of information in them (they change depending on the target architecture).

Target recipes don't install their bindir/sbindir into the sysroot since we can't run them and as you mention, they're the wrong architecture so they confuse strip and so on.

You could try having a native recipe which depended upon this target recipe and which installs the binaries saved by the target recipe somewhere into its ${D} at do_install. That may well give some warnings since in general native recipes shouldn't depend on target recipes but is probably your best option if you can't build twice.

Upvotes: 2

Related Questions