From owner-freebsd-current Tue Oct 13 15:37:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA11321 for freebsd-current-outgoing; Tue, 13 Oct 1998 15:37:08 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from highwind.com (hurricane.highwind.com [209.61.45.50]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA11314 for ; Tue, 13 Oct 1998 15:37:04 -0700 (PDT) (envelope-from info@highwind.com) Received: (from info@localhost) by highwind.com (8.8.6/8.8.6) id SAA07644; Tue, 13 Oct 1998 18:36:10 -0400 (EDT) Date: Tue, 13 Oct 1998 18:36:10 -0400 (EDT) Message-Id: <199810132236.SAA07644@highwind.com> From: HighWind Software Information To: jb@cimlogic.com.au CC: jb@cimlogic.com.au, current@FreeBSD.ORG In-reply-to: <199810132222.IAA05402@cimlogic.com.au> (message from John Birrell on Wed, 14 Oct 1998 08:22:24 +1000 (EST)) Subject: Re: Recent 3.0's are Depressing Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG HighWind Software Information wrote: > Hmm. Wouldn't statically linking OUR local libc_r into the application > make it so the changes to libc_r at the customer site not effect us? > Maybe I am missing something. Ah, sorry. Yes _customer_ site changes would be ruled out by that. I thought you were meaning your development system. Are you saying that you can't duplicate the customer's problem on your system? That is correct. It works like a charm at our site. At 2 different customer sites (both running recent 3.0's), it gets into this problem. At customers running older 3.0 SNAPSHOT's, it works fine. Quite frustrating. Send the application a SIGINFO, then look in /tmp/uthread.dump. We'll get this. -Rob To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message