FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

> From: Strong, Mark [mailto:m.Strong AT tnsa.com.au]
> Sent: October 15, 2002 2:30 AM
> 
>       I'll install whatever, because as you say it would be 
> nice to have it working on all unixs (including HPUX).

Always glad to find another, um, participant. ;)  

> I added LIBS="-ld4r $LIBS" up near the top of the configure 
> script, and now

That was enterprising.  Noted.  

> the configure script seems to be able to work out the correct 
> prototypes for
> the three get*_r() functions, and will now compile with the
> --enable-threadsafe switch (still have some core dumps in 
> dblib unittests, strangely enough less of them).

Mark, have you tried configuring without "--enable-threadsafe"?  If there
are nonthreadsafe issues, I'd like to solve them first, because  not every
HPUX user will need threadsafe operation.   And to simplify our
troubleshooting.  

> Here is a piece of the man page for the functions in HPUX
> ------------------------------------------------------------
> need to include /usr/include/netdb.h.
> 
>  OBSOLESCENT INTERFACES
>       int gethostent_r(struct hostent *result,
>                        struct hostent_data *buffer);
[...]

What were they replaced with?  It would seem there's some other way HPUX
would like us to get the hostname?  

> >If you can provide a bt and a log of the session that dumps core
> a bt ???, logging turns on with an environment var doesn't it ?

Yes, logging is turned on with TDSDUMP,
http://www.freetds.org/userguide/x2052.htm#AEN2056

"bt" means "backtrace"; it's the command you enter in the gdb debugger to
display the call stack.  Its output tells us by what route the program
arrived at the fault, and should tell us on what line it failed.  Just do:

$ gdb <unittest>
GNU gdb 5.0nb1
Copyright 2000 Free Software Foundation, Inc.
[...]
(gdb) run
[message about fault]
(gdb) bt
[stack trace output]
(gdb) quit

Copy the business and paste it here.  Sorry if that was obvious.  Not
everyone reading the list has done it.  

> vasprintf.c: In function `vasprintf':
> vasprintf.c:93: parse error at end of input
> gmake[2]: *** [vasprintf.lo] Error 1
> gmake[2]: Leaving directory 
> `/home/mstrong/freetds-0.60/src/replacements'
> 
> This is from the freetds-current.tgz (not having a good run am I).

Nor I.  The nightly snapshot didn't; cron and I have to have a talk(1).  

Meanwhile, I've posted a current snapshot at
http://www.schemamania.org/freetds-today.tgz.  It won't be very quick to
download from there, but at least it's up to date.  It definitely includes
Nick's repair to the above problem.  

To recap:

Try freetds-today.tgz.
Try without "--enable-threadsafe"
(if that works, great, we're halfway home.)
Turn on logging.
Post the log and the bt for the unittest.
Relax and see what happens.

Regards, 

--jkl


The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above.  If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that for certain accounts we do not accept
orders and/or instructions by e-mail, and for those accounts we will not be
responsible for carrying out such orders and/or instructions. Kindly refrain
from sending orders or instructions by e-mail unless you have confirmed that
we accept such communications for your account. Please also note that to
satisfy regulatory requirements we review the outgoing and incoming e-mail
correspondence of staff members serving certain functions.