On Wed, Sep 13, 2023 at 06:42:11PM -0300, Andreas Hasenack wrote: > > krb5 was a special case because its "internal" symbols used a prefixed name, > > so the glibc implementation was not a drop-in ABI-compatible replacement.
> > For the common case, libraries are providing symbols with the literal names > > "strlcat" and "strlcpy"; if the build system detects these names in the > > system libc it will omit them at build time. Unless there's some extremely > > unusual linkage, reverse-dependencies that need this symbol will then just > > pick it up from libc6 instead. > > So if these library packages pick up a versioned Depends: on libc6 (>= 2.38) > > automatically, no further source changes should be needed. And if they > > don't have a versioned Depends: for some reason, it should be sufficient to > > manually add one. > We still need to address the removal of the strl* symbols from each > library package that previously had it in its d/*.symbols packages, > right? Should we settle on marking them as optional? Yes, you would need to update the .symbols files. I would recommend simply dropping them rather than marking them optional, since if they come back again that indicates a DIFFERENT problem. If you need something upstreamable to Debian, then you'll need to mark them optional since Debian unstable is still on glibc 2.37. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel