FreeTDS Development Group

[Brian Bruns <camber AT ais.org>]

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
>