FreeTDS Development Group

[Steve Langasek <vorlon AT netexpress.net>]

On Thu, 28 Jun 2001, Brian Bruns wrote:

> Well, I haven't heard anything negative about 0.52pre2, so I've placed the
> tag R0_52 on the files in CVS.

> I'll be getting tarballs, rpms, release notes, and stuff together in the
> next few days, but for the impatient you can pull it from CVS now.

> Now, a question regarding the RPM builds, and one of the reasons that
> binaries suck, we have a few possible options for what to do with ODBC.

> 1) don't distribute ODBC drivers
> 2) build against iODBC
> 3) build against unixODBC
> 4) distribute multiple RPMs

> What's the story on the .deb side?

Let me double-check on that. I think I may have been looking at building
against iODBC, because it seemed to work more smoothly that way when I last
tried.  How good is binary-compatibility between iODBC and unixODBC?  The
MyODBC driver already packaged in Debian doesn't specify a dependency on
either, and seems to work with both even though it's built against iODBC's
devel package.

I'll also probably include the ODBC driver in the main freetds package, since
it's on an equal footing with the other two APIs.  There's no hard dependency
on either ODBC manager, so it shouldn't hurt anything to include it.

> Not only that but do I configure for working around the dbm conflict or
> no? I'd like to make the RPMs useful to as wide an audience as possible,
> but I'm dreading making more than 1 or 2 rpms.

I've included the dbm fix in the .debs I've built so far.  I would actually
like to see this as a default option, and have any necessary name-mangling
done in the freetds headerfiles: i.e.,

#define dbopen tdsdbopen

so that we can always avoid the namespace collision without breaking
source-compatibility with existing dblib apps.

Is ABI compatibility with Sybase's dblib a concern?  If we're nowhere close to
being binary-compatible now, then I would think it's ok to redefine the name
of the real function symbol to 'tdsdbopen' across the board.  If we do aspire
to binary-compatibility, there's still a solution -- we can use ELF magic to
make 'dbopen' a weak symbol alias to 'tdsdbopen', in such a way that anything
you compile against dblib will use tdsdbopen, and the 'dbopen' name will still
be available for closed-source apps to use.

I don't know if this technique is available on non-ELF systems, so at the very
least we'd want a way to disable these tricks on platforms that don't support
it.

Steve Langasek
postmodern programmer