Re: Adrien Nader > Nice! Watch out though if you don't use a container: the script can > change your system.
Hi Adrien, thanks for the detailed answers. I was using a chroot, that seems to have been enough isolation. > You also need to run it on armhf to have the correct > machine definitions. ... on i386. I'd think that should give the same answer. > - compat_reports/libpq-dev/lfs_to_time_t/compat_report.html > - compat_reports/libpq-dev/base_to_lfs/compat_report.html That's where I got the "100%" from... > On libpq-dev, I see that there is no LFS effect (abi-compliance-checker > reports 100% compat) but there is a time_t one. > > Looking at the HTML reports, the cause is: > > pqWaitTimed ( int forRead, int forWrite, PGconn* conn, long finish_time ) > > The ABI is therefore time_t-dependant. With an insider POV, you can > maybe find reasons this doesn't matter; that's not something I can do > however. ...Mmmh. I did not get that. Is that because of i386 vs armhf? > Anyway, as I said and after many quirks, I got it to dump and diff: the > ABI of libpg-query-dev is affected by both LFS and time_t. > > NB: I think a-c-c reports symbol changes as removal + addition > > You can review the change summary below. Maybe some symbols are > internal-only, or not actually visible in normal usage, or definitions > of symbols that are not in the package's libs (could be libc for > instance: we can't map symbols from headers to shared objects shipped by > the corresponding library package). I would guess the difference is irrelevant in pracise, but since libpg-query changes sonames fairly often, we dont't have to dig deeper, let's just rename the library and be done. For postgresql-16 (where libpq-dev comes from), the only symbol affected seems to be pqWaitTimed as indicated above. The good news is that the function is only used internally in libpq, and by no external user: https://codesearch.debian.net/search?q=pqWaitTimed&literal=1 https://github.com/search?q=pqWaitTimed&type=code (GitHub finds a bunch of instances, but these are all either PostgreSQL itself, or vendored copies of libpq.) So I think we can safely ignore the difference and not rename libpq5. (It has been named like that for 20 years and I really don't want to break compatibility there.) Christoph
