From owner-freebsd-ports@FreeBSD.ORG Wed Nov 23 02:08:37 2011 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 318E61065677 for ; Wed, 23 Nov 2011 02:08:37 +0000 (UTC) (envelope-from conrads@cox.net) Received: from eastrmfepo201.cox.net (eastrmfepo201.cox.net [68.230.241.216]) by mx1.freebsd.org (Postfix) with ESMTP id BCF5C8FC16 for ; Wed, 23 Nov 2011 02:08:36 +0000 (UTC) Received: from eastrmimpo110.cox.net ([68.230.241.223]) by eastrmfepo201.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20111123020831.YOQI4752.eastrmfepo201.cox.net@eastrmimpo110.cox.net>; Tue, 22 Nov 2011 21:08:31 -0500 Received: from serene.no-ip.org ([98.164.86.236]) by eastrmimpo110.cox.net with bizsmtp id 0S8W1i00K55wwzE02S8Wc9; Tue, 22 Nov 2011 21:08:31 -0500 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020208.4ECC559F.002A,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=1.1 cv=ZOt2FDQ+mrVVVxgXRKzf5SW5Jh1jLT8p/GDSgGTHel4= c=1 sm=1 a=MZZWkA004osA:10 a=G8Uczd0VNMoA:10 a=8nJEP1OIZ-IA:10 a=uAbGmPAyUfLL1M3oYAsfuA==:17 a=TfWq9i5PAAAA:8 a=kviXuzpPAAAA:8 a=x10M4uFVgI4ZWiPThYEA:9 a=PvoXupuQGloC9aSMOdUA:7 a=wPNLvfGTeEIA:10 a=Vce-_cLKp2kA:10 a=4vB-4DCPJfMA:10 a=uAbGmPAyUfLL1M3oYAsfuA==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Received: from cox.net (localhost [127.0.0.1]) by serene.no-ip.org (8.14.5/8.14.5) with ESMTP id pAN28TfG053185; Tue, 22 Nov 2011 20:08:30 -0600 (CST) (envelope-from conrads@cox.net) Date: Tue, 22 Nov 2011 20:08:24 -0600 From: "Conrad J. Sabatier" To: Olivier Smedts Message-ID: <20111122200824.63a8c929@cox.net> In-Reply-To: References: <20111121074243.18902mpt8znqto40@econet.encontacto.net> <20111121100945.2c888eaf@cox.net> <20111121153828.4e04a92a@cox.net> X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.6; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-ports@freebsd.org Subject: Re: Can't compile kde4 and kdelibs4 with an uptodate amd64 Releng machine. ( 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: Wed, 23 Nov 2011 02:08:37 -0000 On Mon, 21 Nov 2011 23:19:08 +0100 Olivier Smedts wrote: > 2011/11/21 Conrad J. Sabatier : > > > > I've been using the (undocumented, at least in /etc/make.conf) > > CPUTYPE?=3Dnative with no problems for quite some time now. =A0Let gcc > > detect the processor type and generate the appropriate code. > > Eliminates any guesswork in trying to select the correct setting for > > CPUTYPE. >=20 > CPUTYPE=3Dnative is not recognized by /usr/share/mk/bsd.cpu.mk (that's > the real purpose of CPUTYPE, it does not only change the -march > compiler setting). > The proper way of doing what you're doing, after numerous tests and > researchs, seems to be : >=20 > CPUTYPE?=3Dcore2 (for example, to let /usr/share/mk/bsd.cpu.mk do its > job) CFLAGS=3D-O2 -pipe -march=3Dnative (because you want the compiler to > detect the cpu it's running on and optimize the code for it) > NO_CPU_CFLAGS=3Dyes (because you wanted to force the -march, you don't > want another one to be added on the command line) > COPTFLAGS=3D-O2 -pipe -march=3Dnative (same thing for kernel CFLAGS) > NO_CPU_COPTFLAGS=3Dyes >=20 > This way, bsd.cpu.mk can set useful MACHINE_CPU for your CPUTYPE, but > you let the compiler determine which processor to optimize the code > for with the -march. I add NO_CPU_CFLAGS and NO_CPU_COPTFLAGS to be > able to specify -march=3Dnative in the CFLAGS, cause it's different from > CPUTYPE. >=20 > Now why do I force -march=3Dcore2 and don't use -march=3Dnative ? Because > our base gcc does not use the correct flags on my Core2 CPU if using > -march=3Dnative : > % /usr/bin/gcc -### -march=3Dnative md5.c > Using built-in specs. > Target: amd64-undermydesk-freebsd > Configured with: FreeBSD/amd64 system compiler > Thread model: posix > gcc version 4.2.1 20070831 patched [FreeBSD] > "/usr/libexec/cc1" "-quiet" "-D_LONGLONG" "md5.c" "-march=3Dcore2" > "-mtune=3Dgeneric" "-quiet" "-dumpbase" "md5.c" "-auxbase" "md5" "-o" > "/var/tmp//ccYJKvGN.s" > "/usr/bin/as" "-Qy" "-o" "/var/tmp//ccR6Lu5X.o" > "/var/tmp//ccYJKvGN.s" "/usr/bin/ld" "--eh-frame-hdr" > "-dynamic-linker" "/libexec/ld-elf.so.1" "/usr/lib/crt1.o" > "/usr/lib/crti.o" "/usr/lib/crtbegin.o" "-L/usr/lib" "-L/usr/lib" > "/var/tmp//ccR6Lu5X.o" "-lgcc" "--as-needed" "-lgcc_s" > "--no-as-needed" "-lc" "-lgcc" "--as-needed" "-lgcc_s" > "--no-as-needed" "/usr/lib/crtend.o" "/usr/lib/crtn.o" >=20 > See the "-mtune=3Dgeneric" ? Crap ! You don't want that (manpage : > Produce code optimized for the most common IA32/AMD64/EM64T > processors. If you know the CPU on which your code will run, then you > should use the corresponding -mtune option instead of -mtune=3Dgeneric. > But, if you do not know exactly what CPU users of your application > will have, then you should use this option.) >=20 > % /usr/bin/gcc -### -march=3Dcore2 md5.c > Using built-in specs. > Target: amd64-undermydesk-freebsd > Configured with: FreeBSD/amd64 system compiler > Thread model: posix > gcc version 4.2.1 20070831 patched [FreeBSD] > "/usr/libexec/cc1" "-quiet" "-D_LONGLONG" "md5.c" "-quiet" > "-dumpbase" "md5.c" "-march=3Dcore2" "-auxbase" "md5" "-o" > "/var/tmp//ccL8Bvk4.s" > "/usr/bin/as" "-Qy" "-o" "/var/tmp//ccLrppPo.o" > "/var/tmp//ccL8Bvk4.s" "/usr/bin/ld" "--eh-frame-hdr" > "-dynamic-linker" "/libexec/ld-elf.so.1" "/usr/lib/crt1.o" > "/usr/lib/crti.o" "/usr/lib/crtbegin.o" "-L/usr/lib" "-L/usr/lib" > "/var/tmp//ccLrppPo.o" "-lgcc" "--as-needed" "-lgcc_s" > "--no-as-needed" "-lc" "-lgcc" "--as-needed" "-lgcc_s" > "--no-as-needed" "/usr/lib/crtend.o" "/usr/lib/crtn.o" >=20 > No -mtune=3Dgeneric. According to the gcc manpage for the x86 arch, > -march=3Dcore2 is sufficient to have proper values for -mtune, -mcpu... > (Generate instructions for the machine type cpu-type. The choices for > cpu-type are the same as for -mtune. Moreover, specifying > -march=3Dcpu-type implies -mtune=3Dcpu-type.) Strange, it seems to "just work" on my machine (note the -march and -mtune settings): $ /usr/bin/gcc -### -march=3Dnative hello.c Using built-in specs. Target: amd64-undermydesk-freebsd Configured with: FreeBSD/amd64 system compiler Thread model: posix gcc version 4.2.1 20070831 patched [FreeBSD] "/usr/libexec/cc1" "-quiet" "-D_LONGLONG" "hello.c" "-march=3Dk8" "-mtune=3Dk8" "-quiet" "-dumpbase" "hello.c" "-auxbase" "hello" "-o" "/tmp/ccAXYamu.s" "/usr/bin/as" "-Qy" "-o" "/tmp/ccIpMJgw.o" "/tmp/ccAXYamu.s" "/usr/bin/ld" "--eh-frame-hdr" "-dynamic-linker" "/libexec/ld-elf.so.1" "/usr/lib/crt1.o" "/usr/lib/crti.o" "/usr/lib/crtbegin.o" "-L/usr/lib" "-L/usr/lib" "/tmp/ccIpMJgw.o" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "-lc" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "/usr/lib/crtend.o" "/usr/lib/crtn.o" I've never seen any problems with this in src or ports makes, either. I do seem to recall having a look at bsd.cpu.mk a long, long time ago, and it appeared to me that it simply passed any unrecognized CPUTYPE through unchanged, which my experience does seem to bear out. --=20 Conrad J. Sabatier conrads@cox.net