FreeTDS Development Group

[Craig Davison <cd AT securityfocus.com>]

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