FreeTDS Development Group

["James K. Lowden" <jklowden AT schemamania.org>]

On Wed, 16 Oct 2002 09:21:23 +1000, "Strong, Mark" <m.Strong AT tnsa.com.au>
wrote:
> James,
>       more results.
> 
> >Mark, have you tried configuring without "--enable-threadsafe"?
> Yep, it compiles (well the freetds-0.60.tgz file did, the newer ones
> have problems compiling), but dblib unittests core dump.

Hmm.  I wish you'd been around when we released it.  I hope you'll be
available for the next iteration.  

> From the manpage
> ***New multithreaded applications should use the regular APIs (those
> without the -r suffix)***
> 
> It appears as if this change happened in the change from HPUX 10.20 to
> HPUX 11.00, as 10.20 seems to still have them in libc (although I don't
> have a 10.20 box to check it, just googled some manpages).

OK, I see.  I'm beyond my ken here.  Not that I mind, but you should know
you're clinging to a drowning man. ;)  I don't know what the right
approach is.  

What basically happens is, you "--enable-threadsafe" and configure hunts
around for threadsafe functional prototypes.  Which it finds, but they're
obsolete as of 11.00 (let's say).  How in the dickens is configure
supposed to know that you've got threadsafe non-_r functions it should
employ instead?  Even if our code didn't assume that threadsafe functions
all had the _r form?  

But I think the solution is: don't try.  FreeTDS is, with one exception
that I can think of, written to be threadsafe.  The purpose of
"--enable-threadsafe" is to control its calls to the OS.  In your case the
"old" calls are themselves threadsafe.  So, no need to use
"--enable-threadsafe".  

(I'd like to know how they pulled that off.  I have it on good authority
from well-known NetBSD people that the old semantics can't be made
threadsafe.)  

> >Try freetds-today.tgz.
> /bin/sh ../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I.
> -I../../include -I../../include    -D_FREETDS_LIBRARY_SOURCE -DTDS70
> -DMSDBLIB -c -o token.lo `test -f 'token.c' || echo './'`token.c
> gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I../../include
> -D_FREETDS_LIBRARY_SOURCE -DTDS70 -DMSDBLIB -c token.c
> -Wp,-MD,.deps/token.TPlo  -fPIC -DPIC -o .libs/token.o
> In file included from token.c:25:
> /opt/gcc/lib/gcc-lib/hppa2.0n-hp-hpux11.00/2.95.2/include/string.h:29:
> warning: conflicting types for built-in function `memcmp'
> /opt/gcc/lib/gcc-lib/hppa2.0n-hp-hpux11.00/2.95.2/include/string.h:85:
> warning: conflicting types for built-in function `memcpy'
> /opt/gcc/lib/gcc-lib/hppa2.0n-hp-hpux11.00/2.95.2/include/string.h:87:
> warning: conflicting types for built-in function `memset'

Maybe you'd better post the prototypes for those three.  Mine for example
looks like this:

     void * memcpy(void *dst, const void *src, size_t len);

Maybe we have to do something different?   <shrug>

> token.c: In function `tds_get_data':
> token.c:1140: `info' undeclared (first use in this function)
> token.c:1140: (Each undeclared identifier is reported only once
> token.c:1140: for each function it appears in.)
> gmake[1]: *** [token.lo] Error 1

I didn't have time to look into this tonight.  I bet Nick or Frediano will
have it fixed in a matter of hours if they haven't already.  

If the snapshot doesn't go off as planned tonight (07:00 UTC), I'll do one
before I go to work (~12:00 UTC).  

--jkl