В сообщении от Воскресенье 25 апреля 2010 21:48:59 автор Tom Rini написал: > Right now, with a big enough BB_NUM_THREADS we can get into a race where > coreutils-native is installing programs and elsewhere we are in a > do_fetch and either trying to use 'cp' or 'md5sum', and blam, we try and > invoke the program while it's being installed (and see things like > sh: /path/to/staging/i686-linux/usr/bin/cp: Textfile is busy). > > There's a few ways out of this: > 1) Don't rely on 'cp' and 'md5sum' anymore but use python for it.
I guess it couldn't really be done, since those could be invoked from any shell script, right? Although it only is a concern for things before do_configure, so there shouldn't be many scripts there. > 2) Make an oe_cp and oe_md5sum to go with oe_sha256sum > 3) IIRC, the big part of coreutils-native was a fully functional, > always, 'install'. We could just copy the install we build or provide > an install wrapper (oe_install) or so We've had install-native, but that was some broken dusty script that act like a detonator - you build some package having it in DEPENDS (not many had, but I was lucky enough) and boom! random packages brake randomly in do_install because of disfunctional install. I've proposed back then to just drop it. But there've been a concern that for reliable builds it's better to be sure that we have known proper install and that is provided by coreutils along with many other things, which are also good to have in some known good state for an OS-independent build system. This is the way we've got to the point of having coreutils-native in all of our builds. Although, as I'm personally building my things on sane GNU hosts with sane coreutils with known nice install, I've always had coreutils-native in ASSUME_PROVIDED. Thus, not seeing any failures with usual 4 bb threads. I guess, if we can solve it with python, it's the best option. If not, then we can try to remove coreutils-native from base dependencies and see how much breakage it introduces. Shouldn't be a problem for most of Linux distros, but for other platforms it may be. -- http://roman.khimov.ru mailto: [email protected] gpg --keyserver hkp://subkeys.pgp.net --recv-keys 0xE5E055C3
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
