Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Bug#1024130: glibc: discuss libutil and libanl libraries for loongarch

50 views
Skip to first unread message

Aurelien Jarno

unread,
Nov 22, 2022, 12:00:04 PM11/22/22
to
Hi,

On 2022-11-15 16:23, 张丹丹 wrote:
> Package: glibc
> Version: 2.36-4
> Severity: wishlist
> Tags: ftbfs patch
> User: debian...@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
aure...@aurel32.net http://www.aurel32.net

zhangdandan

unread,
Nov 25, 2022, 4:00:03 AM11/25/22
to
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 <aur...@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
0 new messages