#105586 unixodbc: SQLConnect.c glibc 2.0.6 bug around is problematical

Package:
unixodbc
Source:
unixodbc
Description:
Basic ODBC tools
Submitter:
Charles C . Fu
Date:
2005-07-18 03:59:57 UTC
Severity:
normal
#105586#5
Date:
2001-07-17 05:27:09 UTC
From:
To:
I am experiencing a strange problem wherein StarOffice on one of my
Debian systems cannot connect to a MySQL database even though
- other Debian systems can use StarOffice to connect to that database
  (via unixODBC) and
- other programs (notably, DataManager) on the affected system can
  connect to the database through unixODBC.

After inserting some debugging statements into the unixODBC sources,
recompiling, and testing, I believe the problem is as follows:

    I believe the glibc 2.0.6 bug workaround at approximately
    SQLConnect.c line 658 (starting with the comment about "big [sic]
    ... with glib 2.0.6" and including the two if statements
    immediately following) might get run even when it shouldn't.  On
    some Debian systems running libc6 2.2.3-5 (but, strangely, not all
    such systems), running the workaround causes unixODBC to work
    incorrectly: the bug workaround wipes out many hooks to the
    underlying loaded ODBC driver (MySQL, MiniSQL, ...), which means
    the unixODBC driver manager no longer has any way to call many
    functions of the underlying driver.

    In particular, on one affected system, using the MySQL ODBC driver
    with Staroffice fails even though DataManager on that system works
    just fine.  I did notice that StarOffice invokes the driver
    through SQLDriverConnect entry point (and winds up resetting the
    pointers returned by lt_dlsym), whereas DataManager uses the
    SQLConnect entry point (and the bug workaround code does nothing,
    as expected).  I do not know if this difference is significant.

    #ifdef'ing out the bug workaround eliminated the problem on the
    affected system, allowing StarOffice to talk happily to MySQL.
    (If necessary, I can provide a patch file.)  I do not yet know if
    this change has any negative repercussions.

The above should probably be forwarded upstream (perhaps to the two
primary authors).  I would have done so myself, but I was unsure of
the recommended address to use for unixODBC bug reports (web site also
has an email support address and addresses for user and developer
lists; but I didn't see instructions on which of these, if any, should
be used for bug reports).

A Debian-specific workaround may be to just remove or comment out
the libc6 2.0.6 workaround above.  The Debian unixodbc package is
declared to depend upon a fairly recent libc6 anyways, so the bug
workaround may be unnecessary.  To be on the safe side, the original
authors should be consulted to see if removing the workaround will
have any negative consequences.
--- Begin /etc/odbcinst.ini (modified conffile)
[myodbc]
Description		= MySQL driver
Driver		= /usr/lib/libmyodbc.so
Setup		= /usr/lib/libodbcmyS.so.1
FileUsage		= 1
CPTimeout		=
CPReuse		=
--- End /etc/odbcinst.ini
#105586#10
Date:
2001-07-29 03:43:49 UTC
From:
To:
forwarded 105586 nick@easysoft.com
thanks

Hi Charles,

Does this mean you've gotten past the problem reported in bug #104505?

Yes, I'll definitely be consulting with the upstream regarding this bug.
Removing this piece of code for Debian is a possibility; glibc 2.0.6 is old
enough that I doubt anyone'll be trying to compile the unixodbc package on
such a system, so I don't have a problem doing that as a temporary fix.

Regards,
Steve Langasek
postmodern programmer