From owner-freebsd-questions@FreeBSD.ORG Mon Aug 18 23:18:28 2008 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64C88106564A for ; Mon, 18 Aug 2008 23:18:28 +0000 (UTC) (envelope-from shonjir@gmail.com) Received: from mail.aerizen.com (mail.aerizen.com [99.12.248.49]) by mx1.freebsd.org (Postfix) with ESMTP id 1AA2E8FC13 for ; Mon, 18 Aug 2008 23:18:28 +0000 (UTC) (envelope-from shonjir@gmail.com) Received: from [192.168.10.37] ([192.168.10.37]) (AUTH: PLAIN john, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by mail.aerizen.com with esmtp; Mon, 18 Aug 2008 15:38:26 -0700 id 0000A92A.48A9F9E2.0000FF04 Message-ID: <48A9F9F3.5030305@gmail.com> Date: Mon, 18 Aug 2008 15:38:43 -0700 From: John Silva User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.16) Gecko/20080708 Thunderbird/2.0.0.16 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: freebsd-questions@freebsd.org References: 26ddd1750808150822r334f800bs73a1117bf310be11@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Working ccache configuration for buildworld on amd64? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2008 23:18:28 -0000 > > On Fri, 15 Aug 2008 11:22:01 -0400 > "Maxim Khitrov" > wrote: > > > >/ I think what's happening is that there is a collision in hash values > />/ generated by ccache. That's the only thing I can think of, because > />/ crt1.c is compiled twice; once from /usr/src/lib/csu/amd64/crt1.c, and > />/ a second time from /usr/src/lib/csu/i386-elf/crt1.c. If LIB32 is > />/ disabled in src.conf, only the first compilation takes place. If the > />/ generated hash values are the same, by some chance, then the actual > />/ problem is that the file is not compiled a second time when, in fact, > />/ it should be. This is only a guess, however. > / > That collision isn't going to happen for several reasons, but it's > missing the point I made earlier, that the build is failing on a cache > miss. If the kind of situation you're describing is happening, then it's > happening earlier, and the observed error is just a side-effect. > Nothing is wrong with ccache; it works just fine. What's happening is that the build system is passing compiler options in the CC variable when invoking make for lib32, and the recommended make.conf config for ccache is blowing those away. Here's how the lib32 build is invoked with ccache enabled: cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj/lib32 _SHLIBDIRPREFIX=/usr/obj/usr/src/lib32 MACHINE=i386 MACHINE_ARCH=i386 INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin CC="/usr/local/libexec/ccache/world-cc -m32 -march=k8 -mfancy-math-387 -DCOMPAT_32BIT -iprefix /usr/obj/usr/src/lib32/usr/ -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32" CXX="/usr/local/libexec/ccache/world-c++ -m32 -march=k8 -mfancy-math-387 -DCOMPAT_32BIT -iprefix /usr/obj/usr/src/lib32/usr/ -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32" OBJC="cc -m32 -march=k8 -mfancy-math-387 -DCOMPAT_32BIT -iprefix /usr/obj/usr/src/lib32/usr/ -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32" LD="ld -m elf_i386_fbsd -Y P,/usr/obj/usr/src/lib32/usr/lib32" AS="as --32" LIBDIR=/usr/lib32 SHLIBDIR=/usr/lib32 make -DNO_CPU_CFLAGS -DCOMPAT_32BIT -DWITHOUT_BIND -DWITHOUT_MAN -DWITHOUT_NLS -DWITHOUT_INFO -DWITHOUT_HTML DESTDIR=/usr/obj/usr/src/lib32 -f Makefile.inc1 libraries cd /usr/src; make -f Makefile.inc1 _prereq_libs; make -f Makefile.inc1 _startup_libs; make -f Makefile.inc1 _prebuild_libs; make -f Makefile.inc1 _generic_libs; Here's how the compiler gets called from the 2nd level make with the recommended settings: /usr/local/libexec/ccache/world-cc -O2 -fno-strict-aliasing -pipe -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 -I/usr/obj/lib32/usr/src/lib/libc -I/usr/src/lib/libc/resolv -DPOSIX_MISTAKE -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c Here's what's supposed to be happening (without ccache): cc -m32 -march=k8 -mfancy-math-387 -DCOMPAT_32BIT -iprefix /usr/obj/usr/src/lib32/usr/ -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32 -O2 -fno-strict-aliasing -pipe -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 -I/usr/obj/lib32/usr/src/lib/libc -I/usr/src/lib/libc/resolv -DPOSIX_MISTAKE -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/libc/i386/gen/_ctx_start.S Notice the difference? Try this instead: # Special ccache for buildworld .if exists(/usr/local/libexec/ccache/world-cc) && !defined(NOCCACHE) && \ (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*)) CC := ${CC:C,^cc,/usr/local/libexec/ccache/world-cc,1} CXX := ${CXX:C,^c\+\+,/usr/local/libexec/ccache/world-c++,1} .endif Instead of hard-configuring CC/CXX, it selectively modifies it only on the first invocation of make. Subsequent invocations are allowed to modify CC as needed using the original (modified) values as a seed. -j