You are not logged in.

#26 2008-06-06 11:38:18

shining
Pacman Developer
Registered: 2006-05-10
Posts: 2,043

Re: (Not-So-Safe) CFlags Discussion ;)

Misfit138 wrote:

Ah, I see your point now, sorry. I have heard conflicting information on this. A dev once told me that makepkg.conf is for makepkg only- not make. He recommended to export the environment variables from rc.conf. Someone else said make an alias for make in .bashrc, which passes the cflags, and I think I read in the wiki that make sources makepkg.conf. I hope a dev can set us all straight on this.
Here's the wiki page which states that makepkg.conf passes variables for make, gcc and makepkg: http://wiki.archlinux.org/index.php/Makepkg.conf
I don't know if it is true.

You say two different things here :
make sources makepkg.conf : that is wrong
makepkg.conf passes variables for make, gcc and makepkg : that is more right but might be a bit misleading

What really happens is what is said on the wiki:

/etc/makepkg.conf contains configuration options for make, makepkg and Gcc. This file is sourced, so you can include any special compiler flags you wish to use. This is helpful for building for different architectures, or with different optimizations. However, only the variables described below are exported to the build environment.

That is, makepkg sources /etc/makepkg.conf and gets the CFLAGS and the other variables that way, then it exports them, and then it calls the build() function of the PKGBUILDs. So the make that is run inside the pkgbuild will use the cflags from makepkg.conf.


pacman roulette : pacman -S $(pacman -Slq | LANG=C sort -R | head -n $((RANDOM % 10)))

Offline

#27 2008-06-06 11:48:42

_Marco_
Member
Registered: 2008-04-21
Posts: 242

Re: (Not-So-Safe) CFlags Discussion ;)

hi shining thanks for the clarification
I've just looked into the makepkg script, I found this:

# ensure all necessary build variables are exported
    export CFLAGS CXXFLAGS MAKEFLAGS CHOST

if I run "export CFLAGS CXXFLAGS MAKEFLAGS CHOST" before the ./configure - make - make install are they automatically used?

edit:
or even better if I put that line in ~/.bashrc

Last edited by _Marco_ (2008-06-06 11:53:10)

Offline

#28 2008-06-06 11:55:34

shining
Pacman Developer
Registered: 2006-05-10
Posts: 2,043

Re: (Not-So-Safe) CFlags Discussion ;)

There is one thing I don't understand : why are there so many people wasting time playing with Cflags who don't even do any benchmarks to see what they gained?
If you have time to waste on this, at least try to do some serious benchmarking.

Hm actually, there is a second thing too, here is how the default makepkg.conf looks like :

  29 #-- Exclusive: will only run on @CARCHFLAGS@
  30 # -march (or -mcpu) builds exclusively for an architecture
  31 # -mtune optimizes for an architecture, but builds for whole processor family
  32 CFLAGS="@CARCHFLAGS@-mtune=generic -O2 -pipe"
  33 CXXFLAGS="@CARCHFLAGS@-mtune=generic -O2 -pipe"

on an i686 box, @CARCHFLAGS@ gets replaced by -march=i686
1) I thought -mcpu was deprecated and got replaced by -mtune, not by -march
2) -march and -mtune are exclusive from the above description, so wtf does having both together do?


pacman roulette : pacman -S $(pacman -Slq | LANG=C sort -R | head -n $((RANDOM % 10)))

Offline

#29 2008-06-06 12:01:34

shining
Pacman Developer
Registered: 2006-05-10
Posts: 2,043

Re: (Not-So-Safe) CFlags Discussion ;)

_Marco_ wrote:

hi shining thanks for the clarification
I've just looked into the makepkg script, I found this:

# ensure all necessary build variables are exported
    export CFLAGS CXXFLAGS MAKEFLAGS CHOST

if I run "export CFLAGS CXXFLAGS MAKEFLAGS CHOST" before the ./configure - make - make install are they automatically used?

edit:
or even better if I put that line in ~/.bashrc

you have to set all these variables before exporting them.
makepkg runs that line after doing source /etc/makepkg.conf, where all these variables are defined (at least the ones who are not commented out).
So you can just put this in your ~/.bashrc to define and export it :
export CFLAGS="-march=native -O2 -pipe"


pacman roulette : pacman -S $(pacman -Slq | LANG=C sort -R | head -n $((RANDOM % 10)))

Offline

#30 2008-06-06 12:05:49

_Marco_
Member
Registered: 2008-04-21
Posts: 242

Re: (Not-So-Safe) CFlags Discussion ;)

aa(... a lot of "a" ...)ah, now I understand...
I'll try ASAP
thanks

Offline

#31 2008-06-06 12:17:56

schivmeister
Developer/TU
From: Singapore
Registered: 2007-05-17
Posts: 971
Website

Re: (Not-So-Safe) CFlags Discussion ;)

I have the following in ~/.bashrc:

. /etc/makepkg.conf

I don't see those variables conflicting with others, unless you have a personal set of those.

If mtune does, by its definition, optimise for one but builds for all, why would there be a need for march? Simple. Having march you can restrict the family:

-march=i686 -mtune=prescott

whereas on the other hand:

-mtune=prescott

would build for i386 too.


I need real, proper pen and paper for this.

Offline

#32 2008-06-06 12:24:20

shining
Pacman Developer
Registered: 2006-05-10
Posts: 2,043

Re: (Not-So-Safe) CFlags Discussion ;)

schivmeister wrote:

I have the following in ~/.bashrc:

. /etc/makepkg.conf

I don't see those variables conflicting with others, unless you have a personal set of those.

If mtune does, by its definition, optimise for one but builds for all, why would there be a need for march? Simple. Having march you can restrict the family:

-march=i686 -mtune=prescott

whereas on the other hand:

-mtune=prescott

would build for i386 too.

In that case, your mtune is more specific than the march though.
What about -march=i686 -mtune=generic?


pacman roulette : pacman -S $(pacman -Slq | LANG=C sort -R | head -n $((RANDOM % 10)))

Offline

#33 2008-06-06 12:53:33

schivmeister
Developer/TU
From: Singapore
Registered: 2007-05-17
Posts: 971
Website

Re: (Not-So-Safe) CFlags Discussion ;)

Good question. I surmise that one has something to do with regards to performance. One of them is more portable than the other, but will not be as optimised since -march restricts to one arch and the -mtune which is, in this case not specific, will include only generic optimisation in order for the binaries to be able to at least run on cpus in the same family.

In the Linux kernel there is a similar option which you can select, CONFIG_X86_GENERIC I think.


I need real, proper pen and paper for this.

Offline

#34 2008-06-06 13:36:02

shining
Pacman Developer
Registered: 2006-05-10
Posts: 2,043

Re: (Not-So-Safe) CFlags Discussion ;)

schivmeister wrote:

Good question. I surmise that one has something to do with regards to performance. One of them is more portable than the other, but will not be as optimised since -march restricts to one arch and the -mtune which is, in this case not specific, will include only generic optimisation in order for the binaries to be able to at least run on cpus in the same family.

I don't understand this at all.
-march=i686 optimizes the binaries for i686 and they will run on all i686. Given that, what is the point of adding -mtune=generic?

Besides the gcc doc states this :

-march=cpu-type
    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.

So we have something like this : -march=i686 -mtune=i686 -mtune=generic?
The only reason I could see is that this was made to confuse everyone smile

As for mcpu:

-mcpu=cpu-type
    A deprecated synonym for -mtune.

Reference : http://gcc.gnu.org/onlinedocs/gcc-4.3.0 … 64-Options


pacman roulette : pacman -S $(pacman -Slq | LANG=C sort -R | head -n $((RANDOM % 10)))

Offline

#35 2008-06-06 14:43:26

Misfit138
Misfit Emeritus
From: USA
Registered: 2006-11-27
Posts: 4,170

Re: (Not-So-Safe) CFlags Discussion ;)

poser.jpg
How could you not laugh at this ^
Ok, carry on.

Offline

#36 2008-06-06 16:54:13

schivmeister
Developer/TU
From: Singapore
Registered: 2007-05-17
Posts: 971
Website

Re: (Not-So-Safe) CFlags Discussion ;)

Ricer!

Anyway, yes - it's too confusing. I've never really bothered and have always used -march by itself, but I've always noticed that combination. From http://www.gentoo.org/doc/en/gcc-optimization.xml:

-mtune produces more generic code than -march; though it will tune code for a certain CPU, it doesn't take into account available instruction sets and ABI.

Say, you have an i686, i586 and i386 machine and you need to share binaries. Compiling on the i686, with -march=i686 -mtune=generic you can run your resulting binaries on the i586 and i386 but the i386 won't perform as well as -march=i386 -mtune=i686, which apparently won't run on the i586 but will be just fine for the i686 as if -march=i686 was used. Of course, -march=i686 by itself you can only run on >=i686. Nevermind, that's all I can gather and I'm confused now =/

Last edited by schivmeister (2008-06-06 17:05:26)


I need real, proper pen and paper for this.

Offline

Board footer

Powered by FluxBB