FreeTDS Development Group

[Brian Bruns <camber AT ais.org>]

On Fri, 29 Jun 2001, Steve Langasek wrote:

> 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.

That would be most cool if they were binary compatible...problem
solved. Can anybody confirm?

> 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

This is a great idea.  I'll squeeze into the 0.52 release...

> 
> 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.
> 
Binary compatibility is not and probably will never be a goal.  Closed
apps are probably operating against sybase anyway and it would obviously
be on a platform that sybase supported, so no biggie if that handful of
apps didn't work.  I can't think of any off the top of my head anyway.

> 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