[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