Shengjing Zhu, le ven. 08 sept. 2023 13:39:10 +0800, a ecrit: > On Fri, Sep 8, 2023 at 1:10 AM Samuel Thibault <sthiba...@debian.org> wrote: > > > > Shengjing Zhu, le ven. 08 sept. 2023 00:05:23 +0800, a ecrit: > > > On Sun, Aug 06, 2023 at 10:30:38AM +0200, Samuel Thibault wrote: > > > > Source: libevent > > > > Version: 2.1.12-stable-8 > > > > Severity: important > > > > Tags: patch > > > > > > > > Hello, > > > > > > > > libevent fails to build against glibc 2.38: > > > > > > > > --- debian/libevent-core-2.1-7.symbols.original 2023-08-06 > > > > 10:17:18.031636016 +0200 > > > > +++ debian/libevent-core-2.1-7.symbols 2023-08-06 > > > > 10:17:28.135665241 +0200 > > > > @@ -310,7 +310,6 @@ > > > > event_set_mem_functions@Base 2.1.8-stable > > > > event_sock_err@Base 2.1.8-stable > > > > event_sock_warn@Base 2.1.8-stable > > > > - (arch=!musl-linux-any)event_strlcpy_@Base 2.1.8-stable > > > > event_warn@Base 2.1.8-stable > > > > event_warnx@Base 2.1.8-stable > > > > > > I don't understand why it's safe to drop this symbol. > > > > Because it's not exposed in the API to other packages: > > > > ./strlcpy-internal.h:#define strlcpy event_strlcpy_ > > > > is the only exposure, and that file is not installed, so there is no way > > for another package to produce a reference to it. I did check on the > > archive in the amd64 case, no package does. > > > > Thanks, that's indeed not possible to use.
That being said, like #1043184 you will need to make libevent-core-2.1-7 Break the previous versions of the other libevent packages, to make sure they get upgraded to the version that doesn't use event_strlcpy_ any more. Samuel
