Arch Linux User Repository

cp: cannot stat `include/config/dvb/*.h': No such file or directory Can you please is some logic like [ -e $FILE ] && cp ... ? makepkg fails with the above otherwise, with some configurations.

I'd really like to use my cent sacks here too. GCC only detects the processor type. Based on that it hands out optimizations specific to that processor (with "-march=native"). Whether or not these optimizations actually work with a 32-bit OS with the smaller address space and all that they don't seem to care. That's why the Gentoo folks created the "safe flags" wiki. Also I don't think t3ddy suddenly decided to like "-march=corei7-avx" either. I think we've proved it doesn't work.

I'm confused as hell by all this... by the way, we should take this discussion to the bbs since many people here only wanna know when the pkg updates. My 2 cents: @t3ddy - 8 GB of RAM = you should run x86_64 :p I have no idea how you could conclude that your Sandybridge requires march=prescott when you proved to me that -march= corei7-avx on your machine (unless GCC is wrong). Just so you know, here is the PKGBUILD, config, and makepkg.conf that my build script made for the corei7-avx i686 packages you're running without issue: PKGBUILD: http://pastebin.com/MXFRfFJh config: http://pastebin.com/uKPh2P1Z makepkg.conf: http://pastebin.com/MBcjaZgY If you really wanna prove to yourself that the gentoo wiki is incorrect about that prescott flag, use the three files I posted to paste bin and build yourself a functional kernel with those flags intact :) Let's please take any future conversation about this topic into the forum. Either t3ddy or Det can start the thread. Thanks!

Ehm... Yes, only 8Gb :/ I've neither thought about it, I've installed i686 because on my old pc (that broke down) I had i686 :P

So far. Nothing mad with using a 32-bit OS on a low RAM environment anyway (it's low with you, right?).

I think I'm the only mad that uses i686 with SandyBridge :)

Great. Now we just need to either have a check for i686/Sandy Bridge systems or remove the whole "-march=native" altogether. For starters I'd suggest something like this (the "AUR post inspector" removes the 2 spaces from the beginning of the make lines) (might not even work - did this in Windows): if [ "$CARCH" = 'i686' ] && [`gcc -c -Q -march=native --help=target|grep march` = *corei7-avx]; then make ${MAKEFLAGS} KCFLAGS="-march=prescott -pipe --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2" KCPPFLAGS="-march=prescott -pipe --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2" bzImage modules else make ${MAKEFLAGS} KCFLAGS="-march=native -pipe --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2" KCPPFLAGS="-march=native -pipe --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2" bzImage modules fi It's just that since there's so many of those CPU generations needing a different "-march" with 32-bit OSes it'd be quite a list to include them all. Having multiple 'linux-ck' packages is not for my liking either.

@Det You got it. Using "-march=prescott" in KC(PP)FLAGS works.

@t3ddy, heh-heh, I'm not expecting you to prove me anything. I _know_ "-march=prescott" is the one you should be using. That's the whole point. The thing is that since: 1) makepkg.conf is not used in any way (even built this kernel with "-march=corei7-avx" just to be sure (I got an AMD CPU)) && 2) "-march=native" corresponds to "-march=corei7-avx" in your system; then you _need_ to try with "-march=prescott" in the KC(PP)FLAGS. Also if you don't like the long compilation times you should set up ccache. It eliminates the need of rebuilding the same stuff.