kernel, userland, and ports CFLAGS

[hanzer]

I just installed 5.6-i386 and I am Building the System from Source. The plan is to first build -release with the default settings, then build -release with the compiler aware of the target machine's CPU architecture, maybe:

CFLAGS="-march=native"
CXXFLAGS="${CFLAGS}"

or:

CFLAGS="-march=prescott"
CXXFLAGS="${CFLAGS}"

If -release compiles smoothly then I will update and compile -stable. Not an efficient process, I know, but I find creeping up on the goal this way develops confidence (and the build automation is impressive, I like to watch it in action).

So, what's the best way to set compiler flags (e.g., -march)? I haven't been able to find anything in the FAQ or man pages. Is there is a way to distinguish between the major regions of the system (kernel, userland, and ports) and set different flags for each?

[jggimi]

I would not recommend this. Setting these flags is not best practice.

Code they produce will take different instruction paths, and you are likely to discover you have race conditions and other bugs that no one else has experienced with your architecture.

I've built this system countless times on multiple architectures and never once touched any of these flags. I recommend you follow that FAQ carefully.

[ocicat]

Originally Posted by hanzer

The plan is to first build -release with the default settings, then build -release with the compiler aware of the target machine's CPU architecture, maybe:

CFLAGS="-march=native"
CXXFLAGS="${CFLAGS}"

or:

CFLAGS="-march=prescott"
CXXFLAGS="${CFLAGS}"

The fact that you used the word "maybe" points out that you are doing this out of curiosity, or mere exploration. That's fine, but if the results crashes & burns, you are on your own.

I have seen this debated countless times on misc@, & the result is always the same -- stay with that is written in release(8) & Section 5.3 of the FAQ.

So, what's the best way to set compiler flags (e.g., -march)?

Do as you please, but the OpenBSD project is small, & the developers have decided not to chase down every possible flag combination possible. I don't blame them; it isn't particularly a valuable use of limited time.

As you get into building from scratch, you will find that it is a very time consuming process. I build -current on a regular basis, usually in response to new versions of specific applications I use being checked into the ports tree. I don't bother with a lot of "What if?" questions because I will be repeating the same process within a month. What you decide for yourself, is your choice, but the culture of this project generally states that going out on a limb needs to be done with grounded reasoning, & an understanding of what the repercussions will be. Straying from the norm is a choice you make; just don't expect the project developers to drop what they are doing to chase down any rabbit holes you may fall into.

Be aware that if you ultimately submit bug reports into the project, they need to be done with full disclosure of any changes from the releases or snapshots found on the mirrors. Any changes not disclosed may result in a lot of wasted time, & blemish your reputation with the developers. The very first question they will ask is what behaviour is seen with the default kernel, userland, & ports without such exotic changes. And they are right in asking such. It saves a lot of time.

Unless you have a specific reason to deviate from the defaults, don't do it. You are on your own if you do.

[hanzer]

Originally Posted by jggimi

I would not recommend this. Setting these flags is not best practice.

Okay, cool. So those knobs aren't presented in the interfaces and the documentation for a reason. (I didn't just overlook something). Cool.

Originally Posted by ocicat

The fact that you used the word "maybe" points out that you are doing this out of curiosity, or mere exploration.

Yep, and an appreciation of ingenuity and craftsmanship.

[hanzer]

When building 3rd party applications from the ports(7) collection, I think I found a fairly straightforward way to inform the compiler of the CPU's capabilities.

bsd.port.mk(5) describes the VARIABLES:

COPTS    
    User settings. Supplementary options appended to ${CFLAGS} for
    building. Since most ports ignore the COPTS convention, they are 
    actually told to use ${CFLAGS} ${COPTS} as CFLAGS.

CXXOPTS    
    User settings. Supplementary options appended to ${CXXFLAGS} 
    for building.

That wasn't terribly clear [to me] but /usr/ports/infrastructure/mk/bsd.port.mk says:

# Add any COPTS to CFLAGS.  Note: programs that use imake do not
# use CFLAGS!  Also, many (most?) ports hard code CFLAGS, ignoring
# what we pass in.
.if defined(COPTS)
CFLAGS += ${COPTS}
.endif 
.if defined(CXXOPTS)
CXXFLAGS += ${CXXOPTS}
.endif

Aha, got it.

Setting COPTS doesn't seem like a contradiction of the design. Rather, this seems to be the intended use. So, a little test:

# cd /usr/ports/net/wget
# make COPTS="-march=native" CXXOPTS="-march=native"
# make install
# make CLEANDEPENDS=Yes clean=all

And it looks like wget and its dependencies were compiled with the -march=native flag. Huzzah!

[jggimi]

Interesting.

• You may find portslogger(1) helpful to track the use of your flags during building.
• Also, you may find time(1) or its shell equivalent helpful when comparing your revised packages with those built by the standard process.