the missing libodbccr.so issue happens when this code runs: https://sources.debian.org/src/unixodbc/2.3.12-1/DriverManager/SQLConnect.c/?hl=2451#L2451
Here we see that, instead of linking libodbccr2, libodbc2 opens it in runtime with dlopen. Hence, at a first glance, libodbc2 should at least suggest libodbccr2 A second issue, as shown by the original report, is that the missing package is unixodbc-dev instead of libodbccr2. This happens because DEFINE_CURSOR_LIB_VER is not defined, as shown in the following snippet: https://sources.debian.org/src/unixodbc/2.3.12-1/DriverManager/SQLConnect.c/?hl=2451#L606. This makes libodbc2 try loading the unbersioned shared library libodbccr.so instead of the versioned one (libodbccr.so.2). This issue affects all supported ubuntu series. Again, at a first look, one may identify 2 fixes being needed here: 1: the unixodbc package should be built with DEFINE_CURSOR_LIB_VER set so the runtime dlopen call looks for the versioned shared object so we do not need to depend on a -dev package in production environments; and 2: libodbc2 should depend, recommend, or at least suggest libodbccr2 The problem is that fix (2) would create a circular dependency since libodbccr2 already depends on libodbc2. Interestingly, none of the binaries are linked against the other. In this case, a solution would indeed be to make php-odbc depend on both libs (or at least suggest/recommend the libodbccr2) after fix (1) is applied. I also wonder if libodbccr2 should really depend on libodbc2 since they are not linked (maybe the dependency should go the other way around, which would be an alternative for fix (2)). This needs further investigation, i.e., we need an answer to "why does libodbccr2 depend on libodbc2?" Finally, regardless of the solution found, it would be nice to discuss this issue with Debian (both with php-odbc and unixodbc maintainers) before commiting to a fix here to avoid carrying a delta indefinitely on one or both these packages. Moreover, I am inclined to say that this change in behavior may not be fit for an SRU depending on how we define what a fix is for this case since this could break working database connections for users (this could work though IF we find out that libodbc2 should depend on libodbccr2). Next steps here would be to file a bug in debian which would reach both php-odbc and unixodbc maintainers and finding the answer to "why does libodbccr2 depend on libodbc2?" A reproducer using lxc is attached. ** Attachment added: "Bug reproducer" https://bugs.launchpad.net/ubuntu/+source/unixodbc/+bug/2085815/+attachment/5834802/+files/reproducer.sh -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2085815 Title: php8.1-odbc missing dependency to unixodbc-dev To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unixodbc/+bug/2085815/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
