From owner-freebsd-current@FreeBSD.ORG Tue Jul 14 10:54:30 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8FED1065670 for ; Tue, 14 Jul 2009 10:54:30 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 5763C8FC23 for ; Tue, 14 Jul 2009 10:54:30 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 6429B1CF29; Tue, 14 Jul 2009 12:54:29 +0200 (CEST) Date: Tue, 14 Jul 2009 12:54:29 +0200 From: Ed Schouten To: Jakub Lach Message-ID: <20090714105429.GL48776@hoeg.nl> References: <24477244.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="i9ck9l8+8M5KOjzp" Content-Disposition: inline In-Reply-To: <24477244.post@talk.nabble.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-current@freebsd.org Subject: Re: Build error "am_ET.UTF-8.out: Inappropriate ioctl for device"" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 10:54:31 -0000 --i9ck9l8+8M5KOjzp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, * Jakub Lach wrote: > =3D=3D=3D> share/mklocale (all) > mklocale -o UTF-8.out /usr/src/share/mklocale/UTF-8.src > mklocale -o am_ET.UTF-8.out /usr/src/share/mklocale/am_ET.UTF-8.src > am_ET.UTF-8.out: Inappropriate ioctl for device It turned out this is because mklocale calls fwrite() with size =3D 0, which will as of recently always cause fwrite() to return 0. I just fixed this in SVN. I discussed this with re@ and for now I'm going to leave fwrite() the way it is. Other operating systems already have this behaviour, so it is very unlikely to cause (major) regressions, especially in third party sources. If other problems arise, I will obviously revert the change and reintegrate it after we've branched RELENG_8. --=20 Ed Schouten WWW: http://80386.nl/ --i9ck9l8+8M5KOjzp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkpcY+UACgkQ52SDGA2eCwXriACfdWNvzYua5NGD7wEa86fLXMq0 vxIAnRBqnO66LyETWequkHY1jVPp8sJv =n7gZ -----END PGP SIGNATURE----- --i9ck9l8+8M5KOjzp--