Can't compile kde4 and kdelibs4 with an uptodate amd64 Releng machine. (

[Conrad J. Sabatier]

On Mon, 21 Nov 2011 23:19:08 +0100
Olivier Smedts <olivier at gid0.org> wrote:

> 2011/11/21 Conrad J. Sabatier <conrads at cox.net>:
> >
> > I've been using the (undocumented, at least in /etc/make.conf)
> > CPUTYPE?=native with no problems for quite some time now.  Let gcc
> > detect the processor type and generate the appropriate code.
> > Eliminates any guesswork in trying to select the correct setting for
> > CPUTYPE.
> 
> CPUTYPE=native 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 :
> 
> CPUTYPE?=core2 (for example, to let /usr/share/mk/bsd.cpu.mk do its
> job) CFLAGS=-O2 -pipe -march=native (because you want the compiler to
> detect the cpu it's running on and optimize the code for it)
> NO_CPU_CFLAGS=yes (because you wanted to force the -march, you don't
> want another one to be added on the command line)
> COPTFLAGS=-O2 -pipe -march=native (same thing for kernel CFLAGS)
> NO_CPU_COPTFLAGS=yes
> 
> 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=native in the CFLAGS, cause it's different from
> CPUTYPE.
> 
> Now why do I force -march=core2 and don't use -march=native ? Because
> our base gcc does not use the correct flags on my Core2 CPU if using
> -march=native :
> % /usr/bin/gcc -### -march=native 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=core2"
> "-mtune=generic" "-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"
> 
> See the "-mtune=generic" ? 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=generic.
> But, if you do not know exactly what CPU users of your application
> will have, then you should use this option.)
> 
> % /usr/bin/gcc -### -march=core2 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=core2" "-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"
> 
> No -mtune=generic. According to the gcc manpage for the x86 arch,
> -march=core2 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=cpu-type implies -mtune=cpu-type.)

Strange, it seems to "just work" on my machine (note the -march and
-mtune settings):

$ /usr/bin/gcc -### -march=native 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=k8"
"-mtune=k8" "-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.

-- 
Conrad J. Sabatier
conrads at cox.net