From owner-freebsd-current Thu Oct 31 6:45:25 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E29E037B401 for ; Thu, 31 Oct 2002 06:45:23 -0800 (PST) Received: from mx2.mail.ru (mx2.mail.ru [194.67.57.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD9B643E6E for ; Thu, 31 Oct 2002 06:45:20 -0800 (PST) (envelope-from kan@mail.ru) Received: from drweb by mx2.mail.ru with drweb-scanned (Exim MX.2) id 187GZM-0000k2-00; Thu, 31 Oct 2002 17:45:12 +0300 Received: from [141.154.54.36] (helo=kan.dnsalias.net) by mx2.mail.ru with esmtp (Exim SMTP.2) id 187GZL-0000ix-00; Thu, 31 Oct 2002 17:45:11 +0300 Received: from kan.dnsalias.net (localhost [IPv6:::1]) by kan.dnsalias.net (8.12.6/8.12.6) with ESMTP id g9VEj8R2061725; Thu, 31 Oct 2002 09:45:08 -0500 (EST) (envelope-from kan@kan.dnsalias.net) Received: (from kan@localhost) by kan.dnsalias.net (8.12.6/8.12.6/Submit) id g9VEixMZ061721; Thu, 31 Oct 2002 09:44:59 -0500 (EST) Date: Thu, 31 Oct 2002 09:44:59 -0500 From: Alexander Kabaev To: Daniel Eischen Cc: ak03@gte.com, tlambert2@mindspring.com, dfr@nlsystems.com, current@FreeBSD.ORG Subject: Re: [PATCH: libc]Re: gnome on current Message-Id: <20021031094459.559e0292.kabaev@bellatlantic.net> In-Reply-To: References: <20021031000501.3e20a6a6.kabaev@bellatlantic.net> Reply-To: ak03@gte.com X-Mailer: Sylpheed version 0.8.5claws26 (GTK+ 1.2.10; i386-portbld-freebsd5.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 31 Oct 2002 09:08:12 -0500 (EST) Daniel Eischen wrote: > > Cool. Then let's be consistent and follow Solaris all the way. Libc > > on Solaris provides full set of pthread_? functions which in turn > > call weakly defined _pthread_?? counterparts. libpthread in turn > > provides strong definitions for _pthread_??. > > No, please see earlier messages in this thread. > Dan, could you please be consistent? You cited Solaris as an example against making all the symbols in libc_r strong. I gave you an answer that the only way why this works on Solaris is because libc itself provides weak pthread_ definitions. pthread_ functions in libc simply call their _pthread counterparts, which are also weekly defined in libc. libpthread defines _pthread_ symbols as strong and consequently its symbols override one provided by libc. Saying 'NO' to strong symbols in libc_r because Solaris does not do that and then saying 'NO' again to description on how Solaris really does things - that's where I lost you. -- Alexander Kabaev To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message