ODBC apps different SQLLEN sizes linked against same DM

[Timothy Parkin]

Research on web / valgrind + driver manager logs / trying 32-bit and 64-bit SQLLEN ODBC drivers indicates that:

* Unified ODBC has been built with 64-bit size SQLLEN types

* PDO ODBC has been built with 32-bit size SQLLEN types

Shouldn't Unified ODBC be linked against a Driver Manager with 64-bit SQLLEN types and PDO ODBC with a Driver Manager that has 32-bit SQLLEN types? In the 64-bit PHP5-ODBC package these ODBC apps are linked against one version of unixODBC.

$ lsb_release -rd
Description: Ubuntu 14.04 LTS
Release: 14.04

$ apt-cache policy php5-odbc
php5-odbc:
  Installed: 5.5.9+dfsg-1ubuntu4
  Candidate: 5.5.9+dfsg-1ubuntu4
  Version table:
 *** 5.5.9+dfsg-1ubuntu4 0
        500 http://gb.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
        100 /var/lib/dpkg/status

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: php5-odbc 5.5.9+dfsg-1ubuntu4
ProcVersionSignature: Ubuntu 3.13.0-24.46-generic 3.13.9
Uname: Linux 3.13.0-24-generic x86_64
ApportVersion: 2.14.1-0ubuntu3
Architecture: amd64
CurrentDesktop: Unity
Date: Thu May 15 09:11:20 2014
InstallationDate: Installed on 2014-05-09 (5 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
ProcEnviron:
 LANGUAGE=en_GB:en
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
SourcePackage: php5
UpgradeStatus: No upgrade log present (probably fresh install)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Chris Allan (episd-callan)]

In addition to this, https://bugs.php.net/bug.php?id=50444 (fixed in 5.5.14) can also cause issues with PHP ODBC x64 and unixODBC 2.2.14 -- may need to be backported?

[Robie Basak (racb)]

Thank you for taking the time to report this bug and helping to make Ubuntu better.

If someone can prepare a backport, please follow the steps at https://wiki.ubuntu.com/StableReleaseUpdates#Procedure to have Trusty updated.

All the steps documented there need to be followed. In particular, I'm concerned that we:

1) Explain the bug well enough so the SRU team (who are probably not familiar with PHP or unixODBC) can understand the real user impact in terms of use case so they can make a decision as to whether backporting the fix to stable releases justifies the regression risk to existing, unaffected users.

2) Make sure that the fixing this in a stable Ubuntu release does not regress existing users of the module not affected by this bug (eg. other architectures or ways of consuming this module).

3) Have a test case that can be followed by someone not familiar with the package for SRU verification purposes.

[Nick Gorham (nifk)]

Can I add a bit of history to this (with my unixODBC hat on). The default SQLLEN for 64 bit platforms changed with the 2.3.0 release of unixODBC, (20th April 2010) from 32 bit to 64 bit. The version number also changed from 1 to 2 to reflect this API change.

A lot of distributions were slow to upgrade their version of unixODBC (Debian changed some time ago, and most are now following or have already done so). Ubuntu has changed in utopic to 2.3.1 as the base which has 64 as the default SQLLEN. Before that the base was 2.2.14 which was released 19th November 2008.

But other than unixODBC versions which may be manageable because of the library version change, the real problem is the driver. Even if by some convoluted manner you had one module linked against libodbc.so.1 and the other libodbc.so.2, if they both wanted to use the same ODBC driver, then you would hit the same problem there.

When I released 2.3.0 it was my hope that driver writers would use it as a opportunity to change from 32 to 64 bit SQLLEN and the problem would just disappear over time. This has happened and most drivers are 64 bit SQLLEN. But any attempt to fix this in PHP in a way that will also just work for older installation will be (IMHO) problematic.

Also FYI, the original cause of the 32/64 problem was Microsoft changing their mind about the size of SQLLEN.

[Robie Basak (racb)]

Thanks Nick, your input is helpful and appreciated.

Thanks also for bumping to the sover to 2 to reflect the change. Distribution packaging understands this and should be able to deal with it well.

I see that the PHP odbc.so and pdo_odbc.so as supplied in Trusty link to libodbc.so.1 only, and Trusty does not supply libodbc.so.2. Both libodbc.so.1 and libodbc.so.2 are shipped in Utopic in the package libodbc1; I'm not sure if this is intentional or is a bug, since normally I'd expect a concurrent libodbc2 to ship libodbc.so.2.

However, at least in 2.3.1-3, libodbc.so.1 is just a symlink to libodbc.so.2. If behaviour has changed, is this a bug?

[Robie Basak (racb)]

From the Debian changelog of the bump to 2.3:

    - Since the library ABI has not changed in Debian (ever), keep the
      package names the same and provide backwards-compatible symlinks to
      avoid an unnecessary library transition; and update the symbols/shlibs
      to make it clear the old versions of the library don't satisfy these
      dependencies any longer.

[Robie Basak (racb)]

15:03 <slangasek> rbasak: Debian and Ubuntu were always using a 64-bit SQLLEN on 64-bit archs despite this not being the upstream ABI, because the upstream ABI was broken and there was no reason to keep compatibility with it

I'm not sure how this fits with "PDO ODBC has been built with 32-bit size SQLLEN types". Does this apply to 32-bit architectures (eg. i386) only, or does that claim include amd64 also? It looks like this bug was filed from an amd64 machine?

[Steve Langasek (vorlon)]

The Debian and Ubuntu unixodbc packages have used a 64-bit SQLLEN from their inception on 64-bit architectures. This was a deviation from the upstream ABI of course, but the upstream ABI was broken on 64-bit systems (as upstream knows, which is why they changed it).

On 32-bit architectures, SQLLEN is 32-bit per the ODBC definition. This has also never changed (upstream or in the distro).