On Wed, 18 Dec 2019 17:24:21 +0100
Alexander Kanavin wrote:
> You can also supply your own definition of ENOATTR, as it doesn't
> change.
That way lies EVEN MORE madness. I don't have any guarantee that it
won't be changed at some point, and... I mean, silly though it sounds
to talk about
On Wed, 18 Dec 2019 at 17:22, Seebs wrote:
> > It won't, as attr upstream moved the definition of ENOATTR from one
> > header file to another.
> >
> > attr is supplied by oe-core though, so we have control over which
> > version is used.
>
> So basically, if I want to maintain support in pseudo
On Wed, 18 Dec 2019 17:15:34 +0100
Alexander Kanavin wrote:
> On Wed, 18 Dec 2019 at 16:27, Seebs wrote:
>
> > On Wed, 18 Dec 2019 15:37:46 +0100
> > Alexander Kanavin wrote:
> >
> > > +Latest versions of attr have removed the xattr.h header,
> > > +with the rationale that libc is providing
On Wed, 18 Dec 2019 at 16:27, Seebs wrote:
> On Wed, 18 Dec 2019 15:37:46 +0100
> Alexander Kanavin wrote:
>
> > +Latest versions of attr have removed the xattr.h header,
> > +with the rationale that libc is providing the same wrappers.
>
> I'm a bit concerned about this -- will this still work
On Wed, 18 Dec 2019 15:37:46 +0100
Alexander Kanavin wrote:
> +Latest versions of attr have removed the xattr.h header,
> +with the rationale that libc is providing the same wrappers.
I'm a bit concerned about this -- will this still work with *older*
versions of xattr?
-s
--
Signed-off-by: Alexander Kanavin
---
...xattr-adjust-for-attr-2.4.48-release.patch | 48 +++
meta/recipes-devtools/pseudo/pseudo_git.bb| 1 +
2 files changed, 49 insertions(+)
create mode 100644
