On 2017-03-20 13:21, Patrick Ohly wrote:
On Mon, 2017-03-20 at 13:12 +0100, Gary Thomas wrote:
I just updated to the latest Poky master (7e0985bab68547) which
replaced rpm-5.4 with rpm-4.13.90 (git). My builds in an existing
tree now fail:
|
/build/p7619_2016-02-23/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/libsolv/0.6.26-r0/recipe-sysroot-native/usr/lib/librpmdb.so:
file not recognized: File format not recognized
| collect2: error: ld returned 1 exit status
| ext/CMakeFiles/libsolvext.dir/build.make:285: recipe for target
'ext/libsolvext.so.0' failed
| make[2]: *** [ext/libsolvext.so.0] Error 1
| make[2]: Leaving directory
'/build/p7619_2016-02-23/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/libsolv/0.6.26-r0/build'
| CMakeFiles/Makefile2:207: recipe for target
'ext/CMakeFiles/libsolvext.dir/all' failed
| make[1]: *** [ext/CMakeFiles/libsolvext.dir/all] Error 2
| make[1]: Leaving directory
'/build/p7619_2016-02-23/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/libsolv/0.6.26-r0/build'
| Makefile:163: recipe for target 'all' failed
| make: *** [all] Error 2
| ERROR: Function failed: do_compile (log file is located at
/build/p7619_2016-02-23/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/libsolv/0.6.26-r0/temp/log.do_compile.8183)
ERROR: Task
(/local/poky-cutting-edge/meta/recipes-extended/libsolv/libsolv_0.6.26.bb:do_compile)
failed with exit code '1'
Looking at this file shows it's a stale symlink:
$ file
/build/p7619_2016-02-23/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/libsolv/0.6.26-r0/recipe-sysroot-native/usr/lib/librpmdb.so
/build/p7619_2016-02-23/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/libsolv/0.6.26-r0/recipe-sysroot-native/usr/lib/librpmdb.so:
symbolic link to librpmdb-5.4.so
$ file `readlink
/build/p7619_2016-02-23/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/libsolv/0.6.26-r0/recipe-sysroot-native/usr/lib/librpmdb.so`
librpmdb-5.4.so: cannot open `librpmdb-5.4.so' (No such file or directory)
Any ideas how to fix this?
The code maintaining the recipe specific sysroots does not always keep
the sysroots in sync with what they should contain, primarily because it
is limited to updating them instead of (at least sometimes) starting
from scratch.
Probably a "bitbake -c clean libsolv && bitbake libsolv" will help in
your case. If it doesn't, try "rm -rf tmp" next (might be faster and
easier too, if more recipes are affected).
Thanks, that did fix it.
I see that those recipe-sysroot* trees are kept around (I don't run rm_work)
For one of my builds which has ~475 packages in tmp/work, they amount to 7GB
Is there any way to prune them?
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
