On Wed, 2015-02-18 at 19:25 +0100, Enrico Scholz wrote: > Armin Kuster <akuster808-re5jqeeqqe8avxtiumw...@public.gmane.org> > writes: > > > Normally, strip preserves hardlinks which in the case of the way our > > hardlink rather than copy functionality works, > > This breaks stripping of hardlinked files. 'package.bbclass' contains > logic to run 'strip' only once per hardlinked file. With this patch, > only one instance gets stripped. > > E.g. the 'e2fsprogs-mke2fs' package contains now > > -rwxr-xr-x 4 root root 350025 Feb 18 01:42 /sbin/mke2fs > -rwxr-xr-x 4 root root 350025 Feb 18 01:42 /sbin/mkfs.ext2 > -rwxr-xr-x 4 root root 350025 Feb 18 01:42 /sbin/mkfs.ext3 > -rwxr-xr-x 4 root root 350025 Feb 18 01:42 /sbin/mkfs.ext4 > -rwxr-xr-x 1 root root 84700 Feb 18 01:42 /sbin/mkfs.ext4dev > > where the first 4 programs (which are one inode with 4 hardlinks) are > not stripped.
There is a problem here for sure. The issue is that for space/performance reasons we hardlink the files in the sysroot with the ones in the packaging process amongst other places. If one set gets stripped, before this patch they'd all get stripped and the process was not deterministic. Were the files in the sysroot stripped or unstripped for example? So the patch addresses a real issue. > > - stripcmd = "'%s' %s '%s'" % (strip, extraflags, file) > > + # Use mv to break hardlinks > > + stripcmd = "'%s' %s '%s' -o '%s.tmp' && mv '%s.tmp' '%s'" % (strip, > > extraflags, file, file, file, file) > > How are these files then merged again? They're not :(. So we have a different problem introduced by the patch. I'll give this a bit more thought overnight. We might need to implement some code to merge these back given we already maintain the lists of files. Cheers, Richard -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core