From owner-freebsd-arch@FreeBSD.ORG  Fri Mar  2 17:38:51 2012
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: arch@FreeBSD.ORG
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id B46EE106566B
	for <arch@FreeBSD.ORG>; Fri,  2 Mar 2012 17:38:51 +0000 (UTC)
	(envelope-from das@FreeBSD.ORG)
Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101])
	by mx1.freebsd.org (Postfix) with ESMTP id 734898FC17
	for <arch@FreeBSD.ORG>; Fri,  2 Mar 2012 17:38:51 +0000 (UTC)
Received: from zim.MIT.EDU (localhost [127.0.0.1])
	by zim.MIT.EDU (8.14.5/8.14.2) with ESMTP id q22HGl6G030007;
	Fri, 2 Mar 2012 12:16:47 -0500 (EST) (envelope-from das@FreeBSD.ORG)
Received: (from das@localhost)
	by zim.MIT.EDU (8.14.5/8.14.2/Submit) id q22HGlXU030006;
	Fri, 2 Mar 2012 12:16:47 -0500 (EST) (envelope-from das@FreeBSD.ORG)
Date: Fri, 2 Mar 2012 12:16:47 -0500
From: David Schultz <das@FreeBSD.ORG>
To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= <des@des.no>
Message-ID: <20120302171647.GA29850@zim.MIT.EDU>
Mail-Followup-To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= <des@des.no>,
	Garrett Wollman <wollman@hergotha.csail.mit.edu>, arch@freebsd.org
References: <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>
	<86d3958cqi.fsf@ds4.des.no>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <86d3958cqi.fsf@ds4.des.no>
Cc: arch@FreeBSD.ORG, Garrett Wollman <wollman@hergotha.csail.mit.edu>
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 <freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Mar 2012 17:38:51 -0000

On Thu, Feb 23, 2012, Dag-Erling Sm?rgrav wrote:
> Garrett Wollman <wollman@hergotha.csail.mit.edu> 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.

If the linker included libiconv automatically, would it be
possible to switch iconv implementations without recompiling, by
using libmap.conf?  Or is the ABI (e.g., type of iconv_t)
incompatible?  If the ABI is different, then we might as well
stick iconv in libc using weak symbols.

> It all boils down to this: do we aspire to SUS conformance?

I think it actually boils down to what the practical benefit is.
Does it create a compatibility nightmare for apps to have to use
the -liconv flag?  Do other platforms require it?  IIRC, we've
been patching ports to include the flag for years.