Bug#1024130: glibc: discuss libutil and libanl libraries for loongarch
Hi,
On 2022-11-15 16:23, 张丹丹 wrote:
> Package: glibc
> Version: 2.36-4
> Severity: wishlist
> Tags: ftbfs patch
> User: debian-devel@lists.debian.org
> Usertags: loongarch64
>
> Dear maintainer(s),
>
> I'm attaching a patch (only to provide the basis for this discussion) as a discussion point.
> Reference to other architectures such as amd64, arm64 and riscv64, we want to be consistent with the Debian community's handling of libanl and libutil libraries,meanwhile follow the rules of glibc upstream.
Thanks for reaching the glibc team. Loongarch is one of the recently
added architecture upstream, and indeed required some adaptation on the
debian side.
> - Loongarch want to use the default libc-dev.install and libc-udeb.install processing methods in glibc package.
> loongson@loongson-pc:zdd/glibc-2.36/debian/debhelper.in$ pwd
> /home/loongson/glibc-2.36/debian/debhelper.in
> loongson@loongson-pc:zdd/glibc-2.36/debian/debhelper.in$ ls libc-udeb.install libc-dev.install
> libc-dev.install libc-udeb.install
The libc-udeb.install change should be fixed in git already, given we
don't need libutil.so.1 in the udeb file anymore (all packages using it
have been rebuilt), I have committed some changes to remove it.
> - Loongarch want to be consistent with the debian community.
> Glibc upstream processes all architectures libanl and libutil in the same way.
> However, libutil and libanl are provided for other architectures in the debian glibc package.
> I survey from the file of glibc-2.36/debian/debhelper.in/libc-dev-alt.lintian-overrides,such as:
> # All functionality formerly implemented in the libraries libpthread,
> # libdl, libutil, libanl has been integrated into libc. For backwards
> # compatibility, empty static archives libpthread.a, libdl.a, libutil.a,
> # libanl.a are provided, so that the linker options keep working.
For libanl.a, I see two options that do not require to patch the
upstream code:
- Creating the empty libanl.a in the debian/rules.d/build.mk like it is
already done for libpthread_nonshared.a. This ensure some portability
for building packages that explicitly link with -lanl. I have no idea
if there are a lot or not.
- Patching providing a loong64 specific file for libc-dev, just like you
did in the attached patch.
Both options look fine for me, I don't really have a preference here.
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
Reply to: