Hi Guillem, 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. > 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. My real question here though is what's the downsides of providing two variants of this symbol (whether with symbol versioning or name redirection). From my pov, this effectively is your option 3 and what I sketched is the most stupid implementation of it. My sketch did assume that libselinux would be built with LFS support everywhere including i386. Enabling that on the upstream side definitely is even better, because it gets us to not have a Debian-specific ABI. > I think there are only three ways to go about this, excluding the t64 > attempt: Thanks for confirming that I've reported a real problem. > If you'd like assistance with trying to get a proposal for 3 to > present upstream I could look into that. But I think they should be > involved early on to see what they'd like to see and what they might > outright reject. >From my naive point of view, this option 3 is the clear winner. Though it all depends on what upstream says. If upstream cooperates on any option, that's better still as we avoid ABI deviation. Going from here, I also looked a bit into whether we could additionally use an upstream-cooperating approach for other packages central to Debian to avoid t64 bumps. pam seems difficult: | extern time_t pam_misc_conv_warn_time; /* time that we should warn user */ | extern time_t pam_misc_conv_die_time; /* cut-off time for input */ We cannot symbol-version these in a reasonable way. All we could do is ask upstream for a real soname bump. We have a slight advantage here: On little endian (such as armhf), we can extend this to 64bit and 32bit accesses will continue to work for small values. However, doing this to m68k would break horribly. I also couldn't find any in-Debian users of these symbols (super merely vendors pam source), so just bumping it and accepting breakage (Guillems option 1) might be worth a go? For libaudit1, I fail to understand why we bump it at all. Both reports look fine to me: https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09:53:00/compat_reports/libaudit-dev/base_to_lfs/compat_report.html https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09:53:00/compat_reports/libaudit-dev/lfs_to_time_t/compat_report.html This does not extend to libauparse0 where the report gives a reason, but libaudit1 is the one that interacts with /usr-move and libauparse0 not, so can we skip the dance for libaudit1? For libtirpc, it is only about rpcb_gettime, which returns time via a time_t* and can indicate success/failure via return. It seems fairly simple to implement ABI duality here and libtirpc already does symbol versioning. Maybe we can also approach upstream about this? For libfuse2, I think the ABI analysis is broken. The base-to-lfs report supposedly is ok https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09:53:00/compat_reports/libfuse-dev/base_to_lfs/compat_report.html and then going lfs-to-time changes ino_t https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09:53:00/compat_reports/libfuse-dev/lfs_to_time_t/compat_report.html while I would have expected ino_t to change with lfs already. Are we sure about this? In any case, this is more of an academic question as adding ABI-duality would be more involved here. Moreover, I don't see any ACC report for libfuse3-dev. Did that fail to analyze? libiw30 only has one affected symbol: iw_print_timeval ( char* buffer, int buflen, struct timeval const* time, struct timezone const* tz ) Providing ABI duality for this seems doable. Moreover, libiw30 already has soname 30, so maybe upstream is open to bumping it again? The resulting library transition is fairly small. ntfs-3g might be worth a second look. It does use time_t and timeval quite a bit, but it seems to do so in inline functions from ntfstime.h and internally use a "typedef sle64 ntfs_time;", so the library might actually be unaffected and automatically provide ABI-duality via inline functions! The lfs side looks less bright as e.g. FILEREADER embeds off_t. I also looked into a few more libraries affected by both /usr-move and time64 and figured that none of the others seems worth a deeper look. In general though approaching upstreams for doing a soname bump to accommodate lfs+time64 seems like a reasonable thing to ask and maybe like 10% agree? Candidates approaching for soname bumps: * libeinfo1 * libgsmme1 * libiv-unidraw2 * libparted-fs-resize0 * libparted2 * librc1 Also when looking into effort, please keep in mind that for every case mentioned in this email, we're looking into adding a protective diversion due to the package rename without so rename and then in forky we'll have to clean up all those diversions, and in forky+1 we'll have to delete the cleanup code, so while investing more now may seem more expensive, it saves later. Helmut