acl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] tools: link libintl if discovered by AM_GNU_GETTEXT


From: Andreas Grünbacher
Subject: Re: [PATCH] tools: link libintl if discovered by AM_GNU_GETTEXT
Date: Sun, 13 Nov 2022 23:50:59 +0100

Am So., 13. Nov. 2022 um 15:16 Uhr schrieb Arsen Arsenović <arsen@aarsen.me>:
>
> Hi Mike,
>
> Mike Frysinger <vapier@gentoo.org> writes:
> > this patch seems to be based on a tree that isn't ours, or requires some
> > other unrelated patches.  can you please use our tree only with no other
> > custom changes ?  as is, it doesn't apply.
> > -mike
>
> Not sure what happened there, to be honest.  Either way, I prepared a
> new patch.  This one should also be more correct.
>
> Tested on x86_64-pc-linux-gnu, via the Gentoo ebuild, and on
> x86_64-linux-mlibc, via the usual, simple autotools build.  On mlibc
> (where the libc does not provide gettext), libintl is properly linked
> into libacl.so:
>
>   [i] ~/.../acl/usr/lib$ eu-readelf --dynamic libacl.so | grep NEEDED
>     NEEDED            Shared library: [libintl.so.9]
>     NEEDED            Shared library: [libattr.so.1]
>     NEEDED            Shared library: [libc.so]
>
> ... and getfacl does run:
>   bash-5.1# getfacl /
>   mlibc: uselocale() is a no-op
>   mlibc: uselocale() is a no-op

But with those mlibc warnings, are the resulting tools actually
useful? This needs to be looked at before applying this change.

Do the warnings correspond to the setlocale() calls in tools/getfacl.c?

>   getfacl: Removing leading '/' from absolute path names
>   # file: .
>   # owner: 1001
>   # group: 1001
>   user::rwx
>   group::r-x
>   other::r-x
>   getfacl: .: No such process (ESRCH)
>
> Bar libc flaws, naturally.
>
> Thanks, and have a good day.
> --
> Arsen Arsenović

Thanks,
Andreas



reply via email to

[Prev in Thread] Current Thread [Next in Thread]