FreeTDS Development Group

["James K. Lowden" <jklowden AT freetds.org>]

On Mon, 10 Oct 2011 21:05:13 +0000 (UTC)
Perl_to_SQL_Server <JGrenetier AT hotmail.com> wrote:

> At the moment I've got loose ends with this 'unixODBC-devel' package
> because:
> 
> - I can't find mention of it in the freeTDS documentation. If this is
> official and definitely needed then it's got to be somewhere in the
> documentation? Unless the '-devel' suffix belongs to standard Linux
> common knowledge and its necessity assumed to be known? 

It's hard to say what's common knowledge these days.  

When Brian say "packaging is distribution specific" he means different
distributions package software differently.  Some have -devel packages
and some don't.  If you want one man's opinion, I don't see the point
of -devel packages.  They add complexity without any utility except the
sparing of a few seconds and a few blocks on the disk.  Feh.  You may
be at this very moment considering adopting the same opinion.  

The FreeTDS UG makes no attempt to guide you through your
distribution's package policy.  Any attempt would be insufficient.
Instead, it basically says you need sql.h, which is basically
right.  ;-)  

I have this issue filed under Know Thy Distribution.  If you say it's
an uninteresting thing to learn at an unopportune time, I agree.  

> Can we bypass unixODBC altogether? I've read a number of times that
> it's recommended but not essential. I had freeTDS tsql working
> without unixodbc, perhaps I can hook it to DBD::ODBC directly? 

Here's the stack:

- libc
- dm
- FreeTDS
- DBD::ODBC
- your application

Each thing links to the thing above it.  As you can see, linking to
"DBD::ODBC directly" has the question upside down.  

http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.help.sdk_12.5.1.aseodbc/html/aseodbc/aseodbc5.htm

That's Sybase's intro to ODBC; it's not specific to Sybase.  It's the
clearest description of a DM I've seen.  The key concept is that the
application (DBD::ODBC in your case) *links* to the DM.  When it passes
the connection string to the DM, the DM parses the string and loads the
appropriate library (driver).  On Linux it uses dlopen(2); on Windows
it uses the Win32 LoadLibrary() function.  

Without a DM to mediate, the application links directly to the library
(libtdsodbc in our case), losing the ability to connect to other
servers with other drivers.  

> conftest.c:65:17: error: sql.h: No such file or directory
> 
> I don't have any "conftest.c" however, is it a file created on the
> fly and deleted after freeTDS ./configure completion?

That might not matter.  config.log can be hard to read, and some errors
are normal, part of the trial-and-error process of establishing what
works on your machine.  

What does "tsql -C" tell you about iconv?  If it says "yes", you're
done compiling and are ready to proceed to local configuration, chapter
4 in the UG.  

If not, it's usually enough to watch what configure writes to standard
output. I like to run it this way:

        $ nohup ../configure $(cat ../.build_options) 

where .build_options has my configure options, and nohup(1) writes
configure's output to nohup.out.  Scan that for odbc messages.  

HTH.

--jkl