Skip to Content.
Sympa Menu

freetds - RE: configure bombs on DU 4.0

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Castellano, Nicholas" <Nicholas_Castellano AT acml.com>
  • To: "'TDS Development Group'" <freetds AT franklin.metalab.unc.edu>
  • Subject: RE: configure bombs on DU 4.0
  • Date: Thu, 12 Sep 2002 09:48:28 -0400


I never bothered to try --enable-threadsafe on Tru64. I'm not personally
interested in threadsafety for my database applications. Only reason I got
wrapped up in that whole threadsafety discussion, was I submitted some code
that wasn't threadsafe, and freddy pointed out that it needed to be made
safe for those who do care about such things.

So, when I started the "configure bombs on DU 4.0" thread, I was just
interested in having "configure" run to completion on this platform. The
checks for gethostbyaddr_r are executed even if you haven't requested
threadsafety, so I needed to fix them to behave correctly on this platform.

That said, if you don't find the solution to this on your own, I can
probably give you a hand in a day or so. I have some other stuff I plan to
commit that I'd like to get sorted out first.

Cheers,
--nick

-----Original Message-----
From: bounce-freetds-145195 AT franklin.oit.unc.edu
[mailto:bounce-freetds-145195 AT franklin.oit.unc.edu]
Sent: Thursday, September 12, 2002 7:18 AM
To: TDS Development Group
Subject: [freetds] RE: configure bombs on DU 4.0


Thats why I reopened this thread addressed to Nick, as he was doing testing
on DU4.0 (aka Tru64) and looking at threadsafe code, I believe.

I've attached the man page, gethostbyaddr_r was not recommended for new code
at that stage!

OS version is 4.0f, was OSF1, then DU, then Tru64, and now HP something,
soon to be assimilated (ie dropped in favour of HPUX :( ).

If noone has this working, I can live without it, I'm afraid that with the
dropping of Tru64 by HP, any corporate support here is evaporating. At a
meeting yesterday I was basically told all the alpha systems will be
replaced by Win2K servers at the next upgrade. Before I get to deploy
FreeTDS in the field. I'm still happy to test on it, though.

David

> -----Original Message-----
> From: ZIGLIO Frediano [mailto:Frediano.Ziglio AT vodafoneomnitel.it]
> Sent: Thursday, 12 September 2002 7:25 PM
> To: TDS Development Group
> Subject: [freetds] RE: configure bombs on DU 4.0
>
>
> > >
> > > Freddy,
> > >
> > > Tests 1-6 core-dump, 7 and 8 both pass.
> > > No freetds.log is generated, but here's a run of t0001 with
> > > resulting core-dump, foloowed by stack traces using first gdb and
> > > then dbx (which seems to grok the libc symbols better).
> > >
> > > Parameters to gethostbyaddr_r look a bit odd, right number, but
> > > strange values. If tds_gethostbyaddr_r is passing a structure
> > > address as the last parameter, how can it be 0 ?
> > >
> >
> > Well... a "man gethostbyaddr_r" should be useful.
> >
> > freddy77
> >
> I found it.
> What version of Tru64 are you using ??
> Version 5 (I don't know earlier) have reentrant gethostbyaddr
> function.
> I think we should change our reentrant implementation for tru64.
> There is a define for tru64 system ?
> Something like
>
> #ifdef __TRU64__
> /* Oh.. tru64 system found */
> #endif
> ??
>
> And to know version ??
>
> freddy77
>
> =================================
> "STRICTLY PERSONAL AND CONFIDENTIAL
>
> This message may contain confidential and proprietary
> material for the sole
> use of the intended recipient. Any review or distribution by others is
> strictly prohibited. If you are not the intended recipient
> please contact
> the sender and delete all copies.
> The contents of this message that do not relate to the
> official business of
> our company shall be understood as neither given nor endorsed by it."
>
> =================================
>
> ---
> You are currently subscribed to freetds as:
> [David.Varley AT alcoa.com.au]
> To unsubscribe, forward this message to
> $subst('Email.Unsub')
>



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.






Archive powered by MHonArc 2.6.24.

Top of Page