Bug#1024130: glibc: discuss libutil and libanl libraries for loongarch
Dear maintainer,
I am glad to receive your reply.
> > 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.
- Besides util and anl, are there any other contents that need to be
adjusted for loongarch?
Please point out(my honor).
> > - 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.
- I have seen the commit(stop installing (now empty) libutil.so.1) from
glibc project.
glibc (2.36-6) UNRELEASED; urgency=medium
[ Aurelien Jarno ]
* debian/debhelper.in/libc-udeb.install: stop installing (now empty)
libutil.so.1, it is not used by any of the udeb in testing/sid.
-- Aurelien Jarno <aurel32@debian.org> Sun, 20 Nov 2022 21:29:52 +0100
- For libutil.so, loongarch use debian/debhelper.in/libc-udeb.install
and be consistent with glibc (2.36-6).
> > - 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.
- For libanl.a, loongarch will choose the first one, like other
architectures.
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 would like to make a brief summary for libanl.a and libutil.a/so.
Loongarch will use the default libc-dev.install and libc-udeb.install
processing methods in glibc package(2.36-6).
So, loongarch don't need to add patch providing a loong64 specific
file for libc-dev and libc-udeb.
- Plesase consider the below patch for loongarch64.
diff --git a/debian/sysdeps/loong64.mk b/debian/sysdeps/loong64.mk
new file mode 100644
index 00000000..582a56fa
--- /dev/null
+++ b/debian/sysdeps/loong64.mk
@@ -0,0 +1,5 @@
+# configuration options for all flavours
+extra_config_options = --enable-multi-arch
+
+# main library
+libc_rtlddir = /lib64
thanks,
Dandan Zhang
Reply to: