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. > I think the bug is same as https://bugs.debian.org/1023284, which needs > workaround to keep the exported symbol with new glibc. Yes, because evutil_secure_rng_add_bytes was really exposed in the API, in /usr/include/event2/util.h Samuel
