Control: forwarded -1 seli...@vger.kernel.org Patch now forwarded upstream for review.
https://lore.kernel.org/selinux/zc6tzkpsyzric...@homer.dodds.net/T/#t On Wed, Feb 14, 2024 at 11:25:26PM -0800, Steve Langasek wrote: > On Wed, Feb 07, 2024 at 09:06:58AM +0100, Helmut Grohne wrote: > > On Wed, Feb 07, 2024 at 04:32:45AM +0100, Guillem Jover wrote: > > > Yes, I'm not sure I understand either. This is what symbol versioning > > > makes possible, even providing different variants for the same symbol, > > > see for example glibc or libbsd. > > > I think symbol versioning is subtly different and glibc does not use > > symbol versioning for e.g. gettimeofday selection. With symbol > > versioning, you select a default version at release time and stick to > > it. In other words, building against the updated libselinux does not > > allow you to use the older 32bit variant of the symbol even if you opt > > out of lfs and time64 and you always get the 64bit symbol. What glibc > > does is a little more fancy than my simplistic #define in that it uses > > asm("name") instead. Still this approach allows for selecting which > > symbol is being used via macros (e.g. _FILE_OFFSET_BITS). Please correct > > me if I am misrepresenting this as my experience with symbol versioning > > is fairly limited. > > Agreed. libselinux as it happens does use a symbol version map so there is > symbol versioning involved in some sense? but not the sense you really mean. > > (We could make the symbol map expose the two different function variants > under the same name but different symbols; that's fine but I'll leave that > for upstream to decide.) > > > > In any case, if going the bi-ABI path, I think upstream should get > > > involved, and the shape of this decided with them. In addition > > > the library should also be built with LFS by the upstream build > > > system, which it does not currently, to control its ABI. > > > I agree that involving upstream is a good idea and my understanding is > > that someone from Canonical is doing that already, which is why the > > schedule was delayed. > > Well, "already" is not exactly correct, but the need to resolve this > critical showstopper bug in libselinux before making changes to the > toolchain behavior in unstable and breaking the world has affected the > timeline, yes. > > I now have a tested patch that I've raised as an MP in salsa: > > https://salsa.debian.org/selinux-team/libselinux/-/merge_requests/9 > > I welcome review from the Debian libselinux maintainers prior to opening a > discussion with upstream. (Which I will plan to do sometime Thursday > US/Pacific) > > -- > 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 -- 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
