From owner-freebsd-ports@FreeBSD.ORG Fri Jan 20 13:32:04 2012 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0B97106566C for ; Fri, 20 Jan 2012 13:32:04 +0000 (UTC) (envelope-from wxs@atarininja.org) Received: from syn.atarininja.org (syn.csh.rit.edu [129.21.49.45]) by mx1.freebsd.org (Postfix) with ESMTP id 74BBD8FC14 for ; Fri, 20 Jan 2012 13:32:04 +0000 (UTC) Received: by syn.atarininja.org (Postfix, from userid 1001) id 8CE1A5C39; Fri, 20 Jan 2012 08:32:03 -0500 (EST) Date: Fri, 20 Jan 2012 08:32:03 -0500 From: Wesley Shields To: rflynn@acsalaska.net Message-ID: <20120120133203.GC70833@atarininja.org> References: <2920.46.129.107.107.1326994994.squirrel@mymail.acsalaska.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2920.46.129.107.107.1326994994.squirrel@mymail.acsalaska.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-ports@freebsd.org, Fernando Apestegu?a Subject: Re: Encoding question X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 13:32:04 -0000 On Thu, Jan 19, 2012 at 08:43:14AM -0900, rflynn@acsalaska.net wrote: > Hi, > > > I'm trying to compile a C++ software on FreeBSD. While compiling, this > > error shows up: > > > > error: stray '\357' in program > > error: stray '\273' in program > > error: stray '\277' in program > > > > This file is reported (by file[1]) to be "UTF-8 Unicode (with BOM) C > > program text, with CRLF line terminators" while the rest of the files > > in the package are "ASCII C program text, with CRLF line terminators". > > While I can convert the file with iconv -c -f utf-8 -t ascii file > > > new_file in the post extract stage, I wonder if there is a more > > suitable way for achieving the same thing. Also I would like to avoid > > this software from depending on iconv. > > You have three options: > - have it fixed upstream; > - post process on extract like above; > - post process releases and roll your own tarball which you host yourself. Be careful doing this third one. Often times (but not always) upstream locations use mirrors to make sure the distfile is always available. If you roll your own, just to fix something which can be so easily patched, and you don't provide similar mirror functionality then you are introducing a single point of failure we should try to avoid. Not to mention you're now going to have to do extra work everytime there is a new release. Either fix it upstream or patch it. -- WXS