pre2?
Brian Bruns
camber at ais.org
Mon Jul 8 18:35:17 EDT 2002
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
>
More information about the FreeTDS
mailing list