10654 2016-11-14 22:49:35 +0000 Investigate binary component functionality 2017-12-06 17:16:26 +0000 1 1 7 Build System, Metadata & Runtime OE-Core core 2.2 x86 Multiple RESOLVED FIXED Medium+ normal 2.3 M1 10663 1 stephano stephano jose.perez.carranza joshuagloe meta.mr.watcher meta.watcher --- --- No (bug/feature does not impact docs) oldest_to_newest 68296 0 stephano 2016-11-14 22:49:35 +0000 Some customers ship BSPs which include binary components, however they do not want to share the source code. There should be some way of checking these binaries at build time to be sure they were built with the correct toolchain. 68827 1 stephano 2016-12-05 00:21:49 +0000 Things we should probably be checking: 1. Check for updates to the BSP that break compatibility 2. Check for customer-layer changes that break compatibility 3. Generate list of checks based on things like objdump, readelf, and ldd 4. Allow list of checks to be configurable (extendable?) by recipes 68828 2 stephano 2016-12-05 00:55:57 +0000 As an example (from PCCG): They have two recipes: 1 for the creation of the binary and another recipe that the customer uses to deploy the binary to their rootfs. Problems they would like to solve: 1. The two recipes do not know about each other, so the user could technically include both recipes (which should throw a very obvious error). 2. If they change the location of libraries, older binaries will no longer be compatible. There is currently no check in place for this situation. They currently use PREFERRED_PROVIDER in the binary recipe, to ensure the correct version is installed. 3. If the customer changes something in their layer which breaks compatibility, the binary will simply break without any warnings or errors at build-time.