From owner-freebsd-arch@FreeBSD.ORG Thu Feb 23 21:24:23 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 059EA106566B for ; Thu, 23 Feb 2012 21:24:23 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id B95B58FC14 for ; Thu, 23 Feb 2012 21:24:22 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id ACF1E66A0; Thu, 23 Feb 2012 21:24:21 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 8118D8B7A; Thu, 23 Feb 2012 22:24:21 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Garrett Wollman References: <4F3C28DD.1020003@FreeBSD.org> <4F3C2D2D.5000402@FreeBSD.org> <4F3E78BA.4060203@FreeBSD.org> <864nupcuvl.fsf@ds4.des.no> <4F3E7B5A.20103@FreeBSD.org> <86zkchbff6.fsf@ds4.des.no> <4F3EADB5.7060008@FreeBSD.org> <20120223170918.GA79013@zim.MIT.EDU> <201202231822.q1NIMQOd020804@hergotha.csail.mit.edu> <201202231926.q1NJQPFa021654@hergotha.csail.mit.edu> Date: Thu, 23 Feb 2012 22:24:21 +0100 In-Reply-To: <201202231926.q1NJQPFa021654@hergotha.csail.mit.edu> (Garrett Wollman's message of "Thu, 23 Feb 2012 14:26:25 -0500 (EST)") Message-ID: <86d3958cqi.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org Subject: Re: bsd/citrus iconv X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 21:24:23 -0000 Garrett Wollman writes: > You missed the bit on the next page: > > It is unspecified whether the libraries libc.a, libm.a, > librt.a, libpthread.a, libl.a, liby.a, or libxnet exist as > regular files. The implementation may accept as -l operands > names of objects that do not exist as regular files. That's entirely academic unless you want to modify gcc and clang to automatically pull in libiconv. The point is that if the iconv extension is implemented, it must be available without requiring additional -l options. It all boils down to this: do we aspire to SUS conformance? However, considering that we currently don't have iconv in base at all, providing it in a separate library is still an improvement on the status quo. So long as it's a temporary measure, and we move it into libc when we deem it production-ready... > (This is from the 2001 approved standard; the text that you're looking > at may differ slightly.) The latest version is at http://pubs.opengroup.org/onlinepubs/009695399/ DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no