FreeTDS Development Group

["Varley, David(CBorn at Alcoa)" <David.Varley AT alcoa.com.au>]

Good stuff, after rebuilding automake and libtool as well, I now
get an identical "configure" when running autogen.sh on Tru64 or
Linux systems :)

After build and install, other problems arose, however :(
I'm blaming CVS state for now. But on the Tru64 system sqsh
refused to run, complaining about incorrect library versions.
So I rebuilt sqsh, now it runs, but fails on the "image"
column from the all_types table as follows:

 bash-2.02# sqsh -S Bakes -U user -P password
 sqsh-2.1 Copyright (C) 1995-2001 Scott C. Gray
 This is free software with ABSOLUTELY NO WARRANTY
 For more information type '\warranty'
 [21] Bakes.Bakes.1> select _image from all_types;
 dsp_desc_bind: Memory alloc failure for native column 1
 [22] Bakes.Bakes.1> quit

On Linux sqsh fails instead with:
 \connect: unable to install message callback

(I haven't recompiled it on Linux yet.)

David

> -----Original Message-----
> From: Steve Langasek [mailto:vorlon AT netexpress.net]
> Sent: Thursday, 10 October 2002 9:15 AM
> To: TDS Development Group
> Subject: [freetds] RE: WARNING: update your autoconf
> 
> 
> On Thu, Oct 10, 2002 at 07:03:33AM +0800, Varley, David(CBorn 
> at Alcoa) wrote:
> > Thanks guys, I think I've got it now :)
> 
> > "configure" is normally regarded as "source" and not changed
> > when building, so its in the right place and running it or
> > "make" should not change anything in the source tree.
> 
> > However the problem I encountered was due to an incorrect
> > "configure" script, and so I needed to regenerate it using
> > autogen.sh
> 
> > The rebuilt "configure" script should be the same on all
> > platforms, however it may vary depending on the tools used
> > to build it. In my case the autoconf was the same, but some
> > other tools had slightly different versions.
> 
> > Another interesting thing I noted was that even when these
> > tools were built from the same source, they themselves could
> > have different versions depending  on the tools they were
> > built with (gcc 2.7/2.96/3.1/3.2 etc). And those tools
> > themselves required the autoconf tools to build, so achieving
> > consistency may require several build cycles. Much fun :)
> 
> "tools" meaning things like autoconf, automake, libtool...?  Most of
> these tools are scripts -- never touched by gcc at all.  Only the
> interpreters (perl, m4, and sh) are compiled, and their 
> behavior should 
> be constant no matter what compiler you use. :)  (Indeed, the 
> behavior 
> of automake & libtool is supposed to be the same no matter what 
> *interpreter* you use.)
> 
> Steve Langasek
> postmodern programmer
>