Skip to Content.
Sympa Menu

freetds - Re: [freetds] [PATCH] make replacements more configurable

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Craig Davison <cd AT securityfocus.com>
  • To: freetds AT lists.ibiblio.org
  • Subject: Re: [freetds] [PATCH] make replacements more configurable
  • Date: Tue, 28 Jan 2003 00:57:27 -0700

On Mon, Jan 27, 2003 at 11:37:32PM -0600, Craig A. Berry wrote:
> A scenario may help clarify one of the potential problems: some
> hypothetical developer distributes a set of FreeTDS object libraries
> in binary and explicitly states that they will work on VMS 7.1 and
> later. A hypothetical COBOL programmer installs these on his 7.2
> system, confident they will work because his system meets the minimum
> OS version requirement. He has to muck about a bit and convert the
> .h files to his own COBOL include files, and he has to concoct
> null-terminated strings to call C functions, but both of these are
> pretty trivial. Soon he is off and running and developing an
> application that uses one of the FreeTDS interfaces. This COBOL
> programmer has never heard of autoconf and does not have a C compiler
> installed on his system, though he does have the C run-time because
> that's part of the OS. One day he upgrades his OS to 7.3-1. The
> next time he builds his application, the link dies with a multiply
> defined symbol error. When he figures out it is one of the FreeTDS
> libraries that is not upward compatible he will rightly consider it
> broken. He can probably work around it by deleting the offending
> module from the library, but that's a hack that shouldn't be
> necessary.

Sorry to take this further OT, but how can you be sure that future C
libraries won't define
some other symbol that freetds defines? Nothing can be infinitely
forward-compatible.

Maybe the solution (fictional ignorant COBOL programmer aside) is to get
autoconf for VMS
(according to http://vms.gnu.org/tasks.html it will build and work) and send
patches to
configure.in etc. That would be very valuable.

> I guess the moral of the story is all of the things that should not
> be assumed: autoconf, Configure, source distribution, and C, for starters.

Consider that this project is targeted to UNIX.

--
Craig Davison
Symantec Corporation
+1 (403) 213-3939 ext. 228




Archive powered by MHonArc 2.6.24.

Top of Page