Buildworld fails

bbzz · Nov 1, 2011

Trying to compile 9-STABLE fails with:

Code:

/usr/scr/kerberos5/tools/make-print-version/../../../crypto/heimdal/lib/vers/make-print-version.c:1:error bad value (core2) for -mtune= switch
make-roken.c:1:error:bad value (core2) for -march= switch
make-roken.c:1:error:bad value (core2) for -mtune= switch
*** Error code 1
*** Error code 2
etc, etc

This is my /etc/make.conf

Code:

CPUTYPE?=             core2
CFLAGS=               -O2 -pipe -fno-strict-aliasing
COPTFLAGS=            -O2 -pipe  -funroll-loops -ffast-math -fno-strict-aliasing
OPTIMIZED_CFLAGS=     YES
BUILD_OPTIMIZED=      YES
WITH_CPUFLAGS=        YES
WITHOUT_DEBUG =       YES
WITH_OPTIMIZED_CFLAGS=YES
NO_PROFILE=           YES
BUILD_STATIC=         YES
NO_LPR=               YES
NO_NIS=               YES
CUPS_OVERWRITE_BASE=  YES
WITHOUT_NOUVEAU=      YES

Same code works on my i7 where I use "noconu" for cpu type.
Looking at the building process however, it looks like "core2" is replaced with "noconu" anyway.

So, what's the deal here and how I fix this?

falkman · Nov 1, 2011

Use:

Code:

CPUTYPE?=native

It builds the code to spec with your machine itself (or at least the closest internal set it has).

I've never had an issue building with it (although it can cause issues down the road at runtime... I strongly advise not to use CPUTYPE [at least from my experiences, especially with clang]).

It seems like you're going a bit overkill on the custom flags and whatnot. It's generally not a good idea. Really, just use the default everything for the world and kernel. The 'ricer' CFLAGS will probably only cause more runtime issues, and not provide any noticeable performance increase. Perhaps you have reasoning for these flags for a certain system, in which case, I don't have a say in the matter.

Regards,
Brandon Falk

wblock@ · Nov 1, 2011

A lot of these cause problems, not solve them. Try commenting out most of them and rebuilding:

Code:

CPUTYPE?=             core2
#CFLAGS=               -O2 -pipe -fno-strict-aliasing
#COPTFLAGS=            -O2 -pipe  -funroll-loops -ffast-math -fno-strict-aliasing
OPTIMIZED_CFLAGS=     YES  # this should only apply to ports
#BUILD_OPTIMIZED=      YES
#WITH_CPUFLAGS=        YES
#WITHOUT_DEBUG =       YES
WITH_OPTIMIZED_CFLAGS=YES  # this should only apply to ports
#NO_PROFILE=           YES
#BUILD_STATIC=         YES
NO_LPR=               YES
NO_NIS=               YES
CUPS_OVERWRITE_BASE=  YES
WITHOUT_NOUVEAU=      YES

Same code works on my i7 where I use "noconu" for cpu type.

That should be nocona.

bbzz · Nov 1, 2011

Sorry, i meant "nocona". These were all configured a while ago; never had a single issue with them, which is why i keep them.

@falkman

That worked. But like I said, not sure what would be issue with "core2", given that it looks like it's just alias for "nocona".

falkman · Nov 1, 2011

bbzz said:
That worked. But like I said, not sure what would be issue with "core2", given that it looks like it's just alias for "nocona".

No clue. I've only used -march=native before. Which compiler are you using, and which version?

bbzz · Nov 1, 2011

I haven't touched that, so I guess it's gcc46. FreeBSD 9 should be using clang now? Like I said it's on default.

falkman · Nov 1, 2011

It'd be gcc(1) 4.2.1 if you haven't played with anything. clang(1) is still in heavy development thus I would not suggest using it unless you want to be involved with the development process. It's stable enough that I'm able to use FreeBSD 10.0 (r226909) with everything built with it (besides wine and lib32 used by wine... working on those bugs), but I've been working with clang(1) for a while now so when I find issues, I usually know the workarounds. Just stick with gcc(1) if you plan on having a life outside of FreeBSD.

As for the actual issue. I'd have to look into it when I have some free time, but there's a good chance I won't get to it. As long as everything works, you should be all set. Just ignore the internals for now.

bbzz · Nov 1, 2011

Thanks again for all the help.
So, is FreeBSD 9 using clang or gcc4.2, do we touch anything when compiling from sources?
Search on installed packages shows I got gcc-4.6.3.
I guess that's used by ports then, but what about system?