Patrick, sorry I didn't put you in cc. My quick&dirty workaround: http://patchwork.openembedded.org/patch/101169/
Cheers Andrea On Tue, Aug 25, 2015 at 3:26 PM, Mark Hatle <mark.ha...@windriver.com> wrote: > On 8/25/15 6:46 AM, Patrick Ohly wrote: > > On Fri, 2015-08-14 at 11:51 +0100, Burton, Ross wrote: > >> > >> On 12 August 2015 at 10:33, Patrick Ohly <patrick.o...@intel.com> > >> wrote: > >> > There's a "xattr" DISTRO_FEATURE that should be respected > >> here for > >> > target builds (and explicitly enabled for native I guess). > >> > >> I can add that check, if you want. > >> > >> > Does enabling xattr mean adding build dependencies? > >> > >> No, the conditional code uses lgetxattr and llistxattr, which > >> are in > >> glibc. > >> > >> > >> From five seconds of google it looks like these are in musl and uclibc > >> too, so I've merged this to MUT as-is. > > > > However, it turned out that the XATTR code also introduces a dependency > > on sys/acl.h: > > > > mkfs.jffs2.c: > > > > #ifndef WITHOUT_XATTR > > #include <sys/xattr.h> > > #include <sys/acl.h> > > #endif > > > > sys/acl.h gets provided by acl, so it may or may not work depending on > > build order and files on the host. > > > > I hadn't caught that because I had only looked at library dependencies, > > sorry for that. > > > > What's the right fix? Add the dependency on acl-native in the native > > case, disable XATTR support for target builds (same state as before) or > > make it somehow depend on both "xattr" and "acl" distro features? > > > > Or only check for "xattr"? I'm uncertain how the two are related. > > > > Use PACKAGECONFIG, add xattr as a configuration that in turn adds the > 'acl' as a > dependency. Then acl-native will automatically be converted from 'acl' if > the > '-native' version is built. > > This is typically how I've seen it implemented in other places. (Not > necessary > xattr.. but with the push for more Linux Security Models coming from users > and > other layers, I think xattr is something we need to make sure really works > properly.) > > --Mark > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core >
-- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
