Skip to Content.
Sympa Menu

freetds - Re: [freetds] headers for odbc functions

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "James K. Lowden" <jklowden AT freetds.org>
  • To: freetds AT lists.ibiblio.org
  • Subject: Re: [freetds] headers for odbc functions
  • Date: Mon, 7 May 2012 19:30:02 -0400

On Mon, 7 May 2012 20:30:27 +0000
"Haszlakiewicz, Eric" <EHASZLA AT transunion.com> wrote:

> Now that I installed unixODBC and configured FreeTDS with that I'm
> able to compile my program. It's a bit confusing since the FreeTDS
> user guide claims it implements the ODBC functions, but it's not
> usable w/o the other package.

To be precise, FreeTDS *does* implement the ODBC functions. It doesn't
include the declarations (the header files) because it shares them with
other ODBC drivers.

I'm open to suggestions. From where I sit, it's a packaging problem.


FreeTDS compiles an ODBC driver in the context of a set of declarations
and symbolic constants that are controlled externally. It requires the
header files in the same way you'd need Firebird headers to build a
Firebird plug-in or (I guess) CUPS headers to build a CUPS driver.

The problem with including those headers in the FreeTDS distibution,
apart from the work involved in doing that and keeping them updated, is
that it wouldn't really help. Instead, the naive user lands a little
deeper in the weeds: compilation might go nicely using the included
headers, but what if they don't match what's installed? How will the
installation process integrate the driver into the existing ODBC
structure?

The best alarm is correct, immediate, and noisy. As it stands, the
user must take some positive action to build the ODBC driver and, if
the headers aren't found, some positive action to get them or point
configure at them. Those requirement go some distance to ensure the
resulting binary will work with the installed Driver Manager.

--jkl




Archive powered by MHonArc 2.6.24.

Top of Page