Skip to Content.
Sympa Menu

freetds - Re: pre2?

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.metalab.unc.edu>
  • Subject: Re: pre2?
  • Date: Mon, 8 Jul 2002 17:35:17 -0400 (EDT)


On Mon, 8 Jul 2002, Lowden, James K wrote:

> > From: Brian Bruns [mailto:camber AT ais.org]
> > Sent: July 8, 2002 3:50 PM
> >
> > maybe tonight if I can fix the !@#$
> > autoconf macro to stop finding Linux as having the wrong
> > getservbyname_r signature.
>
> Ack. I hope my applying that patch last night didn't get in your way.

I guess we'll see ;-)

>
> > OSF/1 as usual seems to be the oddball. I think the linux and solaris
> > styles will be pretty evident if they're wrong, you game for
> > some Tru64 testing?
>
> RSN. I have a small demo coming up on my OSF/1 box, so I'd like to leave it
> alone until then.
>
> What I never solved with OSF/1 was shared libraries with iconv. You
> suggested grabbing libiconv, but I'm pretty sure that wouldn't actually
> help, because under OSF/1 (my version, at least), the .so can't have any
> unresolved references of its own. So, it's a matter of how the .so is
> built, not which implementation to use. If I understand it correctly, I
> think this may become a support problem. I myself can work around it, so if
> it's just me, it's just me.

I think our iconv macro is broken...i looked on the autoconf macro archive
but haven't found anything better, so I may need to roll my own. I'm
aware of one Tru64 box still in existance at work and the admin owes me
one, so I'll see if i can't get an account and have a look...not real soon
though.

> My OSF/1 header file looks like this, BTW:
>
> $ egrep 'get....byname_r' /usr/include/netdb.h
> extern int gethostbyname_r __((const char *, struct hostent *, struct
> hostent_data *));
> extern int getservbyname_r __((const char *, const char *, struct servent *,
> struct servent_data *));

yep thats HAVE_FUNC_GETHOSTBYNAME_R_3 according to the autoconf macro
(others being 5 and 6 for Solaris and Linux respectively IIRC).

>
> > BTW, is everyone comfortable with using './configure; make
> > CFLAGS=-D_REENTRANT' as a method of building FreeTDS with all
> > the thread
> > safe stuff? I'd prefer to have it optional for the time being, until
> > later in the 0.6x series anyway.
>
> should it be "--with-threads" or something like that, eventually?

Eventually, we should autodetect and build threads by default, but it's a
bit late in the game to start making major changes to the default build
before 0.60.

> > I made a couple UG changes (light stuff) but I'll get them
> > checked in at the same time.
>
> I'm working on the Appendices at the moment, no conflict there.

coolness.

> > And hopefully we clobbered the 99% cpu problem, if we could get some
> > testing when pre2 comes out that'd be great to have it wrapped up for
> > 0.60.
>
> Oh? I saw a pile of patches go in, but I didn't realize you'd fixed that.

I simply modified the patch that fixed it to not return FAIL
instead of TDS_ERROR from dblib, so I'm not the one to credit on that one.

> > Other than that, I haven't been keeping the NEWS file up to
> > date like I
> > said I was gonna, so I once again need to go fishing through the
> > source/cvs logs/change logs to get a feature list for the
> > announcement.
>
> Hmm. I probably haven't been much help re the ChangeLog, but the cvs logs
> should help.
>
> Policy question: Why is there a ChangeLog file and how are its contents
> supposed to be different from the cvs log?

ChangeLog should be comprehensive and readable. I'm usually very broad
with my cvs descriptions like 'patch to fix X from Y' whereas the
ChangeLog is more like 'src/tds/convert.c: modified func foo() to fix off
by one error' so it's very specific and very much a pita to maintain but
well worth it two months later when you're wondering what the hell you
were thinking.

> --jkl
>





Archive powered by MHonArc 2.6.24.

Top of Page