Skip to Content.
Sympa Menu

freetds - Re: 0.52 tagged in CVS

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Brian Bruns <camber AT ais.org>
  • To: TDS Development Group <freetds AT franklin.oit.unc.edu>
  • Subject: Re: 0.52 tagged in CVS
  • Date: Fri, 29 Jun 2001 15:53:33 -0400 (EDT)


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





Archive powered by MHonArc 2.6.24.

Top of Page