Date: Wed, 16 Jan 2013 17:25:09 -0600 From: Brooks Davis <brooks@FreeBSD.org> To: Dimitry Andric <dim@FreeBSD.org> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, Brooks Davis <brooks@FreeBSD.org>, src-committers@FreeBSD.org Subject: Re: svn commit: r244401 - in head: contrib/libc-vis include lib/libc/gen Message-ID: <20130116232509.GB29437@lor.one-eyed-alien.net> In-Reply-To: <50F72D46.2090707@FreeBSD.org> References: <201212181637.qBIGbP7e084145@svn.freebsd.org> <50D65630.8010901@FreeBSD.org> <20130110234108.GB79810@lor.one-eyed-alien.net> <50F72D46.2090707@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--5I6of5zJg18YgZEa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 16, 2013 at 11:44:22PM +0100, Dimitry Andric wrote: > On 2013-01-11 00:41, Brooks Davis wrote: > > On Sun, Dec 23, 2012 at 01:54:08AM +0100, Dimitry Andric wrote: > >> On 2012-12-18 17:37, Brooks Davis wrote: > >>> Author: brooks > >>> Date: Tue Dec 18 16:37:24 2012 > >>> New Revision: 244401 > >>> URL: http://svnweb.freebsd.org/changeset/base/244401 > >>> > >>> Log: > >>> Replace our implementation of the vis(3) and unvis(3) APIs with > >>> NetBSD's. This output size limited versions of vis and unvis fun= ctions > >>> as well as a set of vis variants that allow arbitrary characters = to be > >>> specified for encoding. > >> > >> This seems to break bootstrapping in some scenarios, in "stage 4.2: > >> building libraries"; for example, with a test run with gcc on > >> ref10-amd64.f.o I got this: > >> > >> gcc -O2 -pipe -I/scratch2/tmp/dim/head/lib/libc/include -I/scratch2/= tmp/dim/head/lib/libc/../../include -I/scratch2/tmp/dim/head/lib/libc/amd64= -DNLS -D__DBINTERFACE_PRIVATE -I/scratch2/tmp/dim/head/lib/libc/../../con= trib/gdtoa -DINET6 -I/scratch2/tmp/dim/obj/scratch2/tmp/dim/head/lib/libc -= I/scratch2/tmp/dim/head/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/s= cratch2/tmp/dim/head/lib/libc/../../contrib/jemalloc/include -I/scratch2/tm= p/dim/head/lib/libc/../../contrib/tzcode/stdtime -I/scratch2/tmp/dim/head/l= ib/libc/stdtime -I/scratch2/tmp/dim/head/lib/libc/locale -DBROKEN_DES -DPOR= TMAP -DDES_BUILTIN -I/scratch2/tmp/dim/head/lib/libc/rpc -DYP -DNS_CACHING = -D_FREEFALL_CONFIG -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protector -Wsys= tem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-s= ign -c /scratch2/tmp/dim/head/lib/libc/../../contrib/libc-vis/vis.c -o vis.o > >> /scratch2/tmp/dim/head/lib/libc/../../contrib/libc-vis/unvis.c: In fun= ction 'unvis': > >> /scratch2/tmp/dim/head/lib/libc/../../contrib/libc-vis/unvis.c:237: er= ror: 'VIS_NOESCAPE' undeclared (first use in this function) > >> /scratch2/tmp/dim/head/lib/libc/../../contrib/libc-vis/unvis.c:237: er= ror: (Each undeclared identifier is reported only once > >> /scratch2/tmp/dim/head/lib/libc/../../contrib/libc-vis/unvis.c:237: er= ror: for each function it appears in.) > >> /scratch2/tmp/dim/head/lib/libc/../../contrib/libc-vis/unvis.c:241: er= ror: 'VIS_HTTP1808' undeclared (first use in this function) > >> /scratch2/tmp/dim/head/lib/libc/../../contrib/libc-vis/unvis.c:245: er= ror: 'VIS_HTTP1866' undeclared (first use in this function) > >> /scratch2/tmp/dim/head/lib/libc/../../contrib/libc-vis/unvis.c:249: er= ror: 'VIS_MIMESTYLE' undeclared (first use in this function) > >> > >> There should most likely be an explicit -I option to point the compiler > >> at the correct vis.h header during the early stages, otherwise it will > >> pick up /usr/include/vis.h, which does not have several of these new > >> VIS_XXX defines. > > > > Sorry for not following up on this sooner. I've not seen this at all > > and most of my builds are done on an 9.0-STABLE box so vis.h isn't > > updated. Adding > > > > CFLAGS+=3D -I${CURDIR}/../../contrib/libc-vis > > > > to lib/libc/gen/Makefile.inc seems like it should fix this, but I'm > > surprised not to have bumped into this or broken tinderbox. Is there > > anything odd about your buildworld command? >=20 > Not really, the environment was just this: >=20 > 1) Building on ref10-amd64.f.o > 2) CC=3Dgcc, CXX=3Dg++, CPP=3Dgcpp >=20 > Did you manage to reproduce the failure? I never did with a buildworld. I could if I tried to build by hand after touching unvis.c so I added an entry to CFLAGS. I think it's more correct. -- Brooks --5I6of5zJg18YgZEa Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFQ9zbVXY6L6fI4GtQRAnaiAKC0/93L5TRXqaglRv9Tqy+SW9XQQACfTHl4 WqYnE1g2+Z/wDHJSTKYLLNk= =gKJ9 -----END PGP SIGNATURE----- --5I6of5zJg18YgZEa--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130116232509.GB29437>