LinuxQuestions.org - [SOLVED] Is this how you set CFLAGS and other Make options?

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - Is this how you set CFLAGS and other Make options? (https://www.linuxquestions.org/questions/slackware-14/is-this-how-you-set-cflags-and-other-make-options-779444/)

Is this how you set CFLAGS and other Make options?

I've been googling and reading up on how to set build optimizations for my system, and after consulting the Arch Wiki, old threads here, and some mailing lists, I've concluded that the way to set CFLAGS, etc. is by putting this in /etc/profile:

Code:

export CHOST="x86_64-unknown-linux-gnu"

export CFLAGS="-march=native -O2 -pipe"

export CXXFLAGS="$CFLAGS"

export MAKEFLAGS="-j3"

However, I'm not sure if this is correct, since a lot of the sources I checked out were for other Linux distributions and even FreeBSD. I have these questions:

Do I need to put "export" before each line, or would it be sufficient to just have the rest (omitting "export")?

I have export CXXFLAGS="$CFLAGS". On the Arch Wiki, it says to put CXXFLAGS="${CFLAGS}", and in another source it says to just put CXXFLAGS=$CFLAGS. Which one is correct for Slackware?

I set MAKEFLAGS to "-j3" because I have a dual core Intel Core 2 Duo processor, but I've also seen this put as MAKEOPTS. Am I looking for MAKEFLAGS, MAKEOPTS or something else?

For my CHOST, would it be sufficient to put "x86_64" instead of "x86_64-unknown-linux-gnu"? Is it even supposed to be CHOST, or should I be setting ARCH?

I'm running Slackware64 v13.0.

I set my CFLAGS to --march=native because according to the Arch Wiki, gcc is able to detect all possible optimizations and enable them after version 4.3.0, and Slackware has 4.3.3. Is it correct to assume this works fine on Slackware?

Thanks for any help. Hopefully this thread will clear some things up for others wondering about the same topic, too.

Let me give you some information about cariables in shells (sh family, i have no idea about csh family).

if you run thhis : CFLAGS="-O2 -fPIC" make then CFLAGS will be only defined in that command run. it's over CFLAGS define is gone.

if i do export CFLAGS="-O2 -fPIC" then CFLAGS will be defined as "-O2 -fPIC" as long as i don't close that shell. export causes the defined value to become global value. be careful with them and read some sh docs about export for more detail.

if i put export CFLAGS="-O2 -fPIC" in /etc/profile then it is defined almost everywhere (as long as global profile script get run. it's not true always. you may have problems with su and sudo usage. with using su - will make sure that all of the profile scripts will get run).

i find dangerous to use global config to override c flags in compile. howevr adding -j3 to make flags might be a good idea.

Quote:

I set MAKEFLAGS to "-j3" because I have a dual core Intel Core 2 Duo processor, but I've also seen this put as MAKEOPTS. Am I looking for MAKEFLAGS, MAKEOPTS or something else?

For my CHOST, would it be sufficient to put "x86_64" instead of "x86_64-unknown-linux-gnu"? Is it even supposed to be CHOST, or should I be setting ARCH?

I'm running Slackware64 v13.0.

I set my CFLAGS to --march=native because according to the Arch Wiki, gcc is able to detect all possible optimizations and enable them after version 4.3.0, and Slackware has 4.3.3. Is it correct to assume this works fine on Slackware?

Thanks for any help. Hopefully this thread will clear some things up for others wondering about the same topic, too.

using MAKEOPTS would be right one. as much as i understand from make docs (GNU is not known for their gogd documentation. well not everybody can do documentation as SlackWare Folks). , MAKEFLAGS is internal usage variable.

only place i saw ARCH used is SlackBuild scripts. i have no idea if we should define a host variable. i don't thing we need to.

on Patrick's SlackBuilds and on SBo script (including my scripts). CFLAGS="-O2 -fPIC" is used for x86_64 (i have a x84_64 system so i did do a lot of test of this).

a little shell scripting information; use MAKEJ="-j4" when defining it for first time. after that to use that variable use $MAKEJ but not always. it's get complicated i'm not your scripting hacker (i'm not a scripting hacker at all. i can write build scripts. in doubt, test it. it's best way to find the right way).

Most makefiles set CFLAGS explicitly, so defining it in the environment won't affect the build. Gnu autoconf 'configure' scripts do pay attention to it and pass CFLAGS, LDFLAGS, et al along into the generated makefiles. I wouldn't bother setting them in the environment.

Also the old saying is true; premature optimization is the root of all evil. Its unlikely you'll notice any difference with any optimizer tweaking, unless you're running things in timing loops. Better to have something thats actually been tested.

So then all I should really add to /etc/zprofile (which links to /etc/profile) is:

Code:

export MAKEOPTS="-j3"

Right?

But can it really hurt to keep the current configuration (notice I changed MAKEFLAGS to MAKEOPTS)?

Code:

export CHOST="x86_64-unknown-linux-gnu"

export CFLAGS="-march=native -O2 -pipe"

export CXXFLAGS="$CFLAGS"

export MAKEOPTS="-j3"

Quote:

Originally Posted by agi93 (Post 3811798)

Code:

export CHOST="x86_64-unknown-linux-gnu"

export CFLAGS="-march=native -O2 -pipe"

export CXXFLAGS="$CFLAGS"

export MAKEOPTS="-j3"

i don't recomend it. let the programmer decide the optimization. and autogen based compile systems (configure script) already do the needed work. other systems like qmake, cmake do it, too.

Alright. Thanks for your help, everyone! You guys probably spared me some headaches in the future :)

Quote:

Originally Posted by agi93 (Post 3811807)

Alright. Thanks for your help, everyone! You guys probably spared me some headaches in the future :)

what GooseYArd said xplanes why Gentoo is not really stable. optimization is complex work and only real optimization is actually done in asm. MPlayer and FFmpeg configure and makefiles has a lot of point about it. some optimizations breaks the code, while some are not. and actual code tests done in -O0 level.