Skip to Content.
Sympa Menu

freetds - Re: RH 5.1 make (again)

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Brian Bruns <camber AT umcc.ais.org>
  • To: TDS Development Group <freetds AT franklin.oit.unc.edu>
  • Subject: Re: RH 5.1 make (again)
  • Date: Thu, 14 Oct 1999 08:09:39 -0400 (EDT)



I got around this on older redhat version by copying libtool.m4 (from
libtool 1.3.3) to the /usr/share/aclocal directory. I'm not sure this is
the best way but it worked.

The real problem is that freetds uses autoconf is it finds it, and RedHat
is missing some m4 files that would actually make it work. I thought I had
fixed this but apparently not. Any autoconf experts out there? If not
I'll post to usenet and see if I can dig something up.

Brian

Curiously, I just did a make distclean and reconfigured and it did not
attempt to run aclocal for me when I ran make. Hmmm...

On Thu, 14 Oct 1999, Craig Burton wrote:

> Hi folks,
>
> I am keen to set up a replication checker for some SQL7.0
> boxes and have been reading your mails for some time and am keen
> to try freetds again... I have gor the 047pre2, and am running
> Linux RH 5.1. I already have sybase installed etc,
>
> I don't get too far after make, and remember being advised
> that this error was due to me having Linux 5.1. Later, I noticed
> someone had said that this had been fixed. I did a configure
> with tds as 4.2, which went fine.
>
> It is
> >make
> cd . && aclocal
> aclocal: configure.in: 14: macro `AM_PROG_LIBTOOL' not found in library
> make: *** [aclocal.m4] Error 1
>
> hmmmm... please let me know what else you need...
>
> CB
>
> -----Original Message-----
> From: bounce-freetds-92240 AT franklin.oit.unc.edu
> [mailto:bounce-freetds-92240 AT franklin.oit.unc.edu]On Behalf Of Brian
> Bruns
> Sent: Saturday, October 02, 1999 10:14 AM
> To: TDS Development Group
> Subject: [freetds] Re: CT lib source?
>
>
>
>
> On Fri, 1 Oct 1999, Mark Schaal wrote:
>
> > > Perhaps, what is needed is a tds->results_exist similar to the
> > > res_info->rows_exist that is used for DBROWS()? This would allow you to
> > > always know whether the previous result processing found anything or not
> > > and could be cleared on a call to tds_process_row_tokens already in the
> > > TDS_COMPLETED state, allowing ct_results to tell the difference without
> > > the hokey 'empty_res_hack' flag I just introduced.
> > >
> > > What do you think?
> > >
> > > Brian
> >
> > I think tds_process_result_token() needs to be redesigned slightly,
> > but I'm not sure what are the needed/correct changes. The current
> > ct_results() hack isn't pretty. If we need a hack I'd prefer having
> > it in the TDS layer rather than the client libraries.
> >
> > One thing is that I suspect tds_process_result_token() ideally should
> > return twice on an empty select query - once after the result setup
> > information (col_names,col_info) and once for the end token. Well,
> > I know it returns twice now so I should say the returns should better
> > reflect the actual token reads. Currently for an empty result the end
> > token is read in the first call but for a non-empty result the end token
> > is read in the second call. This complicates the logical flow, e.g.
> > this means we can't free res_info on an end token since it might really
> > have been a col_names+col_info+end_token instead.
>
> Can't free res_info on an end token anyway, it is legal for the client to
> check dbhasstat() dbretstat() and others after the query is completely
> processed.
>
> >
> This is how things used to work, then something (PHP I think) needed
> DBROWS() implemented. The problem is that when tds_process_result_tokens
> returns the first time it needs to know whether there are rows or not,
> which means it needs to read the next message. (Granted it could probably
> do an unget after it reads the next token.
>
> So the the stream must be read until 1) a row token 2) another result
> token 3) an end token. Now that I'm looking at it, I want to say there was
> once an tds_unget_byte() after reading an end token in the
> process_result_tokens loop. It definately doesn't look right the way it
> is now.
>
> > Of course I'm being influenced by how ctlib views things and need to
> > check dblib compatability.
> >
> > Another thing is that I keep hearing this whisper in the back of my mind
> > that says "what about compute results?" and that adds complications.
> > For a while I was considering a tds->result_type or res_info->result_type
> > which could be set to REGULAR, COMPUTE, NONE, etc., but when I ran what I
> > hoped would be a simple compute query "select id from items compute
> max(id)"
> > I got something like:
> > col_names
> > col_info
> > token_167 (some compute token)
> > token_168 (compute col_info?)
> > regular rows...
> > compute row
> > which interleaves regular and compute info which I didn't expect. I don't
> > know if anyone much uses "compute" but I'd like to at least make it easy
> > for future support.
> >
> Interesting. I have some preliminary stuff in there that works for simple
> computes, but by no means a complete implementation.
>
> > Mark
> > --
> > Mark J. Schaal Phone: (909)
> 620-7724
> > TST On Ramp Fax: (909) 620-8174
> > System Administrator E-Mail:
> > mark AT tstonramp.com
> >
>
>
> ---
> You are currently subscribed to freetds as: craigb AT ibis.com.au
> To unsubscribe, forward this message to
> $subst('Email.Unsub')
>
> ---
> You are currently subscribed to freetds as: camber AT ais.org
> To unsubscribe, forward this message to $subst('Email.Unsub')
>
>





Archive powered by MHonArc 2.6.24.

Top of Page