From owner-freebsd-toolchain@FreeBSD.ORG Wed Feb 19 08:03:57 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 64513589 for ; Wed, 19 Feb 2014 08:03:57 +0000 (UTC) Received: from nm13-vm8.bullet.mail.ir2.yahoo.com (nm13-vm8.bullet.mail.ir2.yahoo.com [212.82.96.187]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B51011720 for ; Wed, 19 Feb 2014 08:03:56 +0000 (UTC) Received: from [212.82.98.62] by nm13.bullet.mail.ir2.yahoo.com with NNFMP; 19 Feb 2014 08:03:47 -0000 Received: from [46.228.39.87] by tm15.bullet.mail.ir2.yahoo.com with NNFMP; 19 Feb 2014 08:03:47 -0000 Received: from [127.0.0.1] by smtp124.mail.ir2.yahoo.com with NNFMP; 19 Feb 2014 08:03:47 -0000 X-Yahoo-Newman-Id: 306916.31865.bm@smtp124.mail.ir2.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: IW7eg2wVM1nz6LXs6h4IWgr9zZzl6.Bjf88nbGLKrBnn7YB ras9QvOjYlI0vatcMgzWD2lTBDW4qHDCYi2HrlAIw8wEtIXvA6EOv6fPpPni TQhJXpbKZZF6MidS8hcWvXqAvrWJ_d9BHwWv_7zQRxGWiobzYKEtiyhjhBsk uI6Hr9mA4x3tN8htqHlCGTGuNRQ7z8UxP8MqTW8B5wUVVvH0WAsxxsYqMH_H YvLVNglIFDdLdGE5OAAhre1LNovNcxQDJAgD07G0fd39bEZLAc500oPdSlOm GISqTqYGwZvA1Awuj3JlsGlHHB2P1vgpJTxjxf08x4imT3z5p6esGSdI2qWb wOX4Hs4Z6_9LzYTVZSXVr.Y22Tl.yQBjUoYM6wJgr5KDzEhXb1VfK_3tLDaY _uPfGLLFQVm2p9i3r7f1Q7eQKPlyv0b6ZGk_RjFGQLkAYCF69Kjssa8O6OhT sn0wcREAzU83kZl79RFtsNe9Ai0SH4CRNOk547Pzy6ya5x8i1BGKdpuvBgZO uZraoBC20DZ1H.1J3uKWwortNjmIpJOgZv.i8a4APff3QjOwcKTmIR.Klnmb RRlHVMUtnDMl2gXhZOpTYU4eBko42 X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. X-Rocket-Received: from [192.168.119.11] (se@84.154.114.151 with plain [188.125.69.59]) by smtp124.mail.ir2.yahoo.com with SMTP; 19 Feb 2014 08:03:47 +0000 UTC Message-ID: <5304655C.6020604@freebsd.org> Date: Wed, 19 Feb 2014 09:03:40 +0100 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-toolchain@freebsd.org Subject: Re: [CFT] Update to clang 3.4 References: <541C998A-071A-4917-9D91-DD00CB0E2689@FreeBSD.org> <63BD3165-A62E-4FE7-9817-4A2692584916@bsdimp.com> <264FAA6E-871A-48AF-A8D9-EC431A537195@FreeBSD.org> <6766B735-98CB-4F1D-B3B5-A43D81BB558A@FreeBSD.org> <52D286BE.7000102@kbh.biglobe.ne.jp> <50EAAC3C-2D38-4409-B525-2608D39BFE70@FreeBSD.org> In-Reply-To: <50EAAC3C-2D38-4409-B525-2608D39BFE70@FreeBSD.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Dimitry Andric X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 08:03:57 -0000 Am 12.01.2014 17:21, schrieb Dimitry Andric: > On 12 Jan 2014, at 13:12, Yamaya Takashi wrote: >> buildworld is failed when WITH_LLDB= > > Yes, this is a known issue. I discussed it with Ed Maste. Clang 3.4 > will have to be imported first, afterwards we can fix lldb. > > >> some ports cannot build. >> >> reason1: clang cannot handle some options. >> (libmad build) >> cc: error: unknown argument: '-fforce-addr' >> cc: error: unknown argument: '-fthread-jumps' >> cc: error: unknown argument: '-fcse-follow-jumps' >> cc: error: unknown argument: '-fcse-skip-blocks' >> cc: error: unknown argument: '-fregmove' >> cc: error: unknown argument: '-fschedule-insns2' >> (libtheora build) >> cc: error: unknown argument: '-fforce-addr' >> (poppler build) >> c++: error: unknown argument: '-fno-check-new' >> (py27-sqlite build) >> cc: error: unknown argument: '-R/usr/local/lib' >> (tbb build) >> c++: error: unknown argument: '-fno-schedule-insns2' >> (gstreamer-ffmpeg build) >> cc: error: unknown argument: '-fno-force-addr' Wouldn't it be best to put automatic fixup makros into ports/Mk/ that remove the unsupported options from all files named "Makefile.in", "Makefile", "configure", "CMakeLists.txt" (and probably many more I forgot), if compiled with CLANG? I just fixed a few of the KDE ports and their dependencies that way, but I think it is very annoying that our ports' Makefiles will need such option fixup in literally hundreds to thousands of places. This will put a penalty on all port build times, but this effect could be minimized by making the fixup conditional not only on CLANG and the CLANG version used, but also on the presence of *_CONFIGURE etc. in the particular port's Makefile. Regards, STefan From owner-freebsd-toolchain@FreeBSD.ORG Thu Feb 20 17:11:07 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 845731B9 for ; Thu, 20 Feb 2014 17:11:07 +0000 (UTC) Received: from aslan.scsiguy.com (ns1.scsiguy.com [70.89.174.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 619FB1848 for ; Thu, 20 Feb 2014 17:11:06 +0000 (UTC) Received: from mollyrector-02.sldomain.com (207-225-98-3.dia.static.qwest.net [207.225.98.3]) (authenticated bits=0) by aslan.scsiguy.com (8.14.7/8.14.7) with ESMTP id s1KHACgX055545 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 20 Feb 2014 10:11:05 -0700 (MST) (envelope-from gibbs@freebsd.org) From: "Justin T. Gibbs" Content-Type: multipart/mixed; boundary="Apple-Mail=_E8F4FF85-F9F7-4544-A5F4-0A5E3B2ACCD2" Subject: ctfconvert broken for C++ objects? Message-Id: <216B816A-8ADA-438F-B834-8C386C5BC460@FreeBSD.org> Date: Wed, 19 Feb 2014 17:16:35 -0700 To: freebsd-toolchain@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 17:11:07 -0000 --Apple-Mail=_E8F4FF85-F9F7-4544-A5F4-0A5E3B2ACCD2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I noticed that ctfmerge was warning about missing CTF data when = compiling =93PROG_CXX=94 programs. I tracked this down to missing = ctfconvert calls when compiling C++ objects. Unfortunately, ctfconvert = segfaults in libdwarf on all of the C++ code I tried. Attached is a = quick hack to avoid the segfault, but I=92m hoping someone here with = more dwarf experience can point me in the right direction for a real = fix. Is this a known issue? I=92m testing this on a FreeBSD stable/9 from ~November of last year. Thanks, Justin --Apple-Mail=_E8F4FF85-F9F7-4544-A5F4-0A5E3B2ACCD2 Content-Disposition: attachment; filename=ctf_for_c++.diffs Content-Type: application/octet-stream; name="ctf_for_c++.diffs" Content-Transfer-Encoding: 7bit Change 1041767 by justing@justing_ns1_spectrabsd on 2014/02/17 10:41:25 Add CTF (required for DTrace) support for C++ programs. share/mk/bsd.lib.mk: share/mk/sys.mk: Add missing CTF convert calls to C++ -> object file transformation rules. Affected files ... ... //SpectraBSD/stable/share/mk/bsd.lib.mk#11 edit ... //SpectraBSD/stable/share/mk/sys.mk#8 edit Differences ... ==== //SpectraBSD/stable/share/mk/bsd.lib.mk#11 (text) ==== @@ -89,18 +89,27 @@ .cc.o .C.o .cpp.o .cxx.o: ${CXX} ${STATIC_CXXFLAGS} ${CXXFLAGS} -c ${.IMPSRC} -o ${.TARGET} + ${CTFCONVERT_CMD} -.cc.po .C.covo .cpp.covo .cxx.covo: +.cc.covo .C.covo .cpp.covo .cxx.covo: ${CXX} ${COVO_FLAG} ${STATIC_CXXFLAGS} ${COVO_CXXFLAGS} -c ${.IMPSRC} -o ${.TARGET} + @[ -z "${CTFCONVERT}" -o -n "${NO_CTF}" ] || \ + (${ECHO} ${CTFCONVERT} ${CTFFLAGS} ${.TARGET} && \ + ${CTFCONVERT} ${CTFFLAGS} ${.TARGET}) .cc.po .C.po .cpp.po .cxx.po: ${CXX} ${PO_FLAG} ${STATIC_CXXFLAGS} ${PO_CXXFLAGS} -c ${.IMPSRC} -o ${.TARGET} + ${CTFCONVERT_CMD} .cc.So .C.So .cpp.So .cxx.So: ${CXX} ${PICFLAG} -DPIC ${SHARED_CXXFLAGS} ${CXXFLAGS} -c ${.IMPSRC} -o ${.TARGET} + ${CTFCONVERT_CMD} .cc.covSo .C.covSo .cpp.covSo .cxx.covSo: ${CXX} ${PICFLAG} ${COVO_FLAG} -DPIC ${SHARED_CXXFLAGS} ${CXXFLAGS} ${COVO_CXXFLAGS} -c ${.IMPSRC} -o ${.TARGET} + @[ -z "${CTFCONVERT}" -o -n "${NO_CTF}" ] || \ + (${ECHO} ${CTFCONVERT} ${CTFFLAGS} ${.TARGET} && \ + ${CTFCONVERT} ${CTFFLAGS} ${.TARGET}) .f.covo: ${FC} ${COVO_FLAG} ${FFLAGS} -o ${.TARGET} -c ${.IMPSRC} ==== //SpectraBSD/stable/share/mk/sys.mk#8 (text) ==== @@ -233,9 +233,11 @@ .cc .cpp .cxx .C: ${CXX} ${CXXFLAGS} ${LDFLAGS} ${.IMPSRC} ${LDLIBS} -o ${.TARGET} + ${CTFCONVERT_CMD} .cc.o .cpp.o .cxx.o .C.o: ${CXX} ${CXXFLAGS} -c ${.IMPSRC} + ${CTFCONVERT_CMD} .m.o: ${OBJC} ${OBJCFLAGS} -c ${.IMPSRC} Change 1041820 by justing@justing_ns1_spectrabsd on 2014/02/17 11:42:29 Prevent ctfconvert segfault while processing certain C++ libraries. lib/libdwarf/dwarf_attrval.c: Don't segfault when an attribute lookup for an anonymous type fails. It looks like this failure may have been introduced in revision 662563 (SVN rev 248641) in FreeBSD. This change prevents the segfault, but doesn't address root cause. Upstream has moved to a new version of libdwarf/libelf, and we will update to that version first to see if the problem is still present, before debugging this further. Affected files ... ... //SpectraBSD/stable/lib/libdwarf/dwarf_attrval.c#3 edit Differences ... ==== //SpectraBSD/stable/lib/libdwarf/dwarf_attrval.c#3 (text) ==== @@ -243,6 +243,9 @@ DWARF_SET_ERROR(err, DWARF_E_BAD_FORM); ret = DWARF_E_BAD_FORM; } + } else { + DWARF_SET_ERROR(err, DWARF_E_BAD_FORM); + ret = DWARF_E_BAD_FORM; } if (ret == DWARF_E_NONE) { --Apple-Mail=_E8F4FF85-F9F7-4544-A5F4-0A5E3B2ACCD2-- From owner-freebsd-toolchain@FreeBSD.ORG Thu Feb 20 17:24:55 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5FC7F55A; Thu, 20 Feb 2014 17:24:55 +0000 (UTC) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2B9A5195B; Thu, 20 Feb 2014 17:24:54 +0000 (UTC) Received: from [192.168.0.7] (cpc28-cmbg15-2-0-cust64.5-4.cable.virginm.net [86.27.189.65]) (authenticated bits=0) by theravensnest.org (8.14.7/8.14.5) with ESMTP id s1KHOXdN017461 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 20 Feb 2014 17:24:42 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: ctfconvert broken for C++ objects? From: David Chisnall In-Reply-To: <216B816A-8ADA-438F-B834-8C386C5BC460@FreeBSD.org> Date: Thu, 20 Feb 2014 17:24:18 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <216B816A-8ADA-438F-B834-8C386C5BC460@FreeBSD.org> To: "Justin T. Gibbs" X-Mailer: Apple Mail (2.1827) Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 17:24:55 -0000 We're likely to keep hitting these. Ideally, we should replace the = libdwarf usage in ctfconvert with either the LLVM or LLDB dwarf parsing, = which is getting to be quite mature now and can handle complex = encodings. The DWARF5 spec is due out this year and LLVM is already = implementing (disabled by default) several of the proposed extensions to = DWARF4 that are likely to make it into DWARF5. =20 David On 20 Feb 2014, at 00:16, Justin T. Gibbs wrote: > I noticed that ctfmerge was warning about missing CTF data when = compiling =93PROG_CXX=94 programs. I tracked this down to missing = ctfconvert calls when compiling C++ objects. Unfortunately, ctfconvert = segfaults in libdwarf on all of the C++ code I tried. Attached is a = quick hack to avoid the segfault, but I=92m hoping someone here with = more dwarf experience can point me in the right direction for a real = fix. Is this a known issue? >=20 > I=92m testing this on a FreeBSD stable/9 from ~November of last year. >=20 > Thanks, > Justin >=20 > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to = "freebsd-toolchain-unsubscribe@freebsd.org" From owner-freebsd-toolchain@FreeBSD.ORG Thu Feb 20 17:26:16 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1EEDE587; Thu, 20 Feb 2014 17:26:16 +0000 (UTC) Received: from vlakno.cz (mail.vlakno.cz [95.129.96.251]) by mx1.freebsd.org (Postfix) with ESMTP id D7CCB1963; Thu, 20 Feb 2014 17:26:15 +0000 (UTC) Received: by vlakno.cz (Postfix, from userid 1002) id 7B0531CC5562; Thu, 20 Feb 2014 18:26:08 +0100 (CET) Date: Thu, 20 Feb 2014 18:26:08 +0100 From: Roman Divacky To: "Justin T. Gibbs" Subject: Re: ctfconvert broken for C++ objects? Message-ID: <20140220172608.GA85526@freebsd.org> References: <216B816A-8ADA-438F-B834-8C386C5BC460@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <216B816A-8ADA-438F-B834-8C386C5BC460@FreeBSD.org> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 17:26:16 -0000 The dwarf backend for ctfconvert was completely reimplemented a few weeks ago. It's now based on elftoolchain libdwarf. Test on current. On Wed, Feb 19, 2014 at 05:16:35PM -0700, Justin T. Gibbs wrote: > I noticed that ctfmerge was warning about missing CTF data when compiling ?PROG_CXX? programs. I tracked this down to missing ctfconvert calls when compiling C++ objects. Unfortunately, ctfconvert segfaults in libdwarf on all of the C++ code I tried. Attached is a quick hack to avoid the segfault, but I?m hoping someone here with more dwarf experience can point me in the right direction for a real fix. Is this a known issue? > > I?m testing this on a FreeBSD stable/9 from ~November of last year. > > Thanks, > Justin > > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to "freebsd-toolchain-unsubscribe@freebsd.org" From owner-freebsd-toolchain@FreeBSD.ORG Fri Feb 21 22:48:05 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3E1D0A47; Fri, 21 Feb 2014 22:48:05 +0000 (UTC) Received: from aslan.scsiguy.com (www.scsiguy.com [70.89.174.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 088DF1617; Fri, 21 Feb 2014 22:48:04 +0000 (UTC) Received: from dansodjalt.sldomain.com (207-225-98-3.dia.static.qwest.net [207.225.98.3]) (authenticated bits=0) by aslan.scsiguy.com (8.14.7/8.14.7) with ESMTP id s1LMluRC065995 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 21 Feb 2014 15:47:57 -0700 (MST) (envelope-from gibbs@FreeBSD.org) Content-Type: multipart/mixed; boundary="Apple-Mail=_1D5A962F-BDAC-4038-8308-CC0D06F6C254" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: ctfconvert broken for C++ objects? From: "Justin T. Gibbs" In-Reply-To: <20140220172608.GA85526@freebsd.org> Date: Fri, 21 Feb 2014 15:47:52 -0700 Message-Id: <81C07491-7E51-4CF0-B257-88ED998EE2A0@FreeBSD.org> References: <216B816A-8ADA-438F-B834-8C386C5BC460@FreeBSD.org> <20140220172608.GA85526@freebsd.org> To: Roman Divacky X-Mailer: Apple Mail (2.1827) Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 22:48:05 -0000 --Apple-Mail=_1D5A962F-BDAC-4038-8308-CC0D06F6C254 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Feb 20, 2014, at 10:26 AM, Roman Divacky = wrote: > The dwarf backend for ctfconvert was completely reimplemented a few = weeks ago. > It's now based on elftoolchain libdwarf. >=20 > Test on current. The failures I=92ve experienced occur when attempting to ctfconvert the = C++ code in the base (e.g. ATF or devd). You can replicate the failures = on head by applying the share/mk patch below (a version of my previous = patch rebased on head). On a slightly related node, do you know why there is a FreeBSD version = ranged exclusion around bootstrapping the dtrace tools? =46rom src/Makefile.inc1: # dtrace tools are required for older bootstrap env and cross-build = =20 .if ${MK_CDDL} !=3D "no" && \ = =20 ((${BOOTSTRAPPING} < 1000034 && \ = =20 !(${BOOTSTRAPPING} >=3D 901505 && ${BOOTSTRAPPING} < 999999)) = \ =20 || (${MACHINE} !=3D ${TARGET} || ${MACHINE_ARCH} !=3D = ${TARGET_ARCH})) =20 _dtrace_tools=3D cddl/usr.bin/sgsmsg cddl/lib/libctf lib/libelf \ = =20 lib/libdwarf cddl/usr.bin/ctfconvert cddl/usr.bin/ctfmerge = =20 .endif We had to disable this protection in our build so that the fixes to the = dtrace tool chain took effect prior to compiling any C++ code during = buildworld. In testing this on head, I also found that 9-stable=92s g++ segfaulted = when bootstrapping clang, so I had to buildworld using 9-stable=92s = clang to get past the bootstrap phase. (By 9-stable, I mean a 9-stable = tree from October/November from last year). =97 Justin --Apple-Mail=_1D5A962F-BDAC-4038-8308-CC0D06F6C254 Content-Disposition: attachment; filename=ctf_for_c++.diffs Content-Type: application/octet-stream; x-unix-mode=0644; name="ctf_for_c++.diffs" Content-Transfer-Encoding: 7bit Index: bsd.lib.mk =================================================================== --- bsd.lib.mk (revision 262298) +++ bsd.lib.mk (working copy) @@ -80,12 +80,15 @@ .cc.o .C.o .cpp.o .cxx.o: ${CXX} ${STATIC_CXXFLAGS} ${CXXFLAGS} -c ${.IMPSRC} -o ${.TARGET} + ${CTFCONVERT_CMD} .cc.po .C.po .cpp.po .cxx.po: ${CXX} ${PO_FLAG} ${STATIC_CXXFLAGS} ${PO_CXXFLAGS} -c ${.IMPSRC} -o ${.TARGET} + ${CTFCONVERT_CMD} .cc.So .C.So .cpp.So .cxx.So: ${CXX} ${PICFLAG} -DPIC ${SHARED_CXXFLAGS} ${CXXFLAGS} -c ${.IMPSRC} -o ${.TARGET} + ${CTFCONVERT_CMD} .f.po: ${FC} -pg ${FFLAGS} -o ${.TARGET} -c ${.IMPSRC} Index: sys.mk =================================================================== --- sys.mk (revision 262298) +++ sys.mk (working copy) @@ -246,9 +246,11 @@ .cc .cpp .cxx .C: ${CXX} ${CXXFLAGS} ${LDFLAGS} ${.IMPSRC} ${LDLIBS} -o ${.TARGET} + ${CTFCONVERT_CMD} .cc.o .cpp.o .cxx.o .C.o: ${CXX} ${CXXFLAGS} -c ${.IMPSRC} + ${CTFCONVERT_CMD} .m.o: ${OBJC} ${OBJCFLAGS} -c ${.IMPSRC} --Apple-Mail=_1D5A962F-BDAC-4038-8308-CC0D06F6C254--