You are not logged in.
Pages: 1
I have been doing alot of reading today on ABS, makepkg etc... I have one question, I think I know the answer but, I'm not sure. Does pacman check the make.conf for cflags prior to package download to insure native support?
Last edited by plat (2014-08-26 02:04:29)
Offline
man pacman.conf | less -p Architecture
Offline
It is shown as it was set prior to x86_64. I reset the cflag to -march=native now. Will pacman pick up on that new cflag setting in make.conf or is there a way to reset the uname -m output? The needed one is march=ivybridge in ieu of the generic version.
EDIT: Sorry I'm getting addicted...lol
Last edited by plat (2014-08-26 02:16:46)
Offline
Oh, I misread your question. -march=native will be picked up whe you run makepkg. What do you mean "reset uname -m" output?
Offline
First I assume you mean makepkg.conf not make.conf. Second, pacman installs precompiled binaries, so they are not optimized for your specific processor, they are compiled for either generic i686 or x86_64. The settings in makepkg.conf only apply to packages that you rebuild locally with makepkg.
EDIT: In principle one could make repositories with precompiled binaries for specific processors - but the arch repos are not that.
Last edited by Trilby (2014-08-26 02:54:20)
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
Oh, I misread your question. -march=native will be picked up whe you run makepkg. What do you mean "reset uname -m" output?
When you type uname -m is shows x86_64 being the kernal type, if applicable. I was curious if you could get pacman to pull the necessary packages to make it custom for your native cpu. Trilby answered the question I believe, but that's what I was wondering. It sure would be cool if pacman could do it custom on the fly...
EDIT: Yes sorry makepkg.conf
Last edited by plat (2014-08-26 03:08:15)
Offline
The coolness you are looking for is typically provided by source-based distros e.g. Gentoo etc. It is, of course, possible to rebuild all your Arch packages for your particular cpu yourself, if you really want to, but your wish that pacman might do it on the fly will never come true.
Offline
I'm Arch for the win. Arch can do everything Gentoo can from what I read and seen via ABS, makepkg & SVN. I went from 17 years of windows to mint for a week then Arch. I figured, if I'm going to learn linux, I ought to learn it on the best distro & one that acts like linux; not a plug and play distro i.e mint... I really like the Arch approach to software management. Gentoo is interesting but, you're stuck compiling for every install (yuck). I can see doing it with programs that are process heavy but, most packages aren't the former. Arch does both precompiled fast install & the makepkg, ABS etc... The best of both worlds. I was just thinking, after Trilby's reading recommendations, that having the added option within pacman would be cool. It would seems to fit into the Arch K.I.S.S. motto. Whether it happens or not doen't much matter to me.
Offline
@plat --- the functionality you desire is already provided by the ABS, surely?
Just recompile whatever packages you want with the optimised flags & there you are..
Offline
I think the exact functionality desired would require many more subdirectories within each of the repos. Currently core, extra, and community each have two subdirectories: i686, x86_64. It sounds like plat was hoping to install precompiled binaries for his specific processor which - and this is the key part as to why it can't be done - would require many new subdirectories: one for i686-core2, x86_64-core2, i686-some-other, x86_64-some-other, etc, etc.
Pacman currently would work just fine with such precompiled binaries. The limitation is simply that no one has seen sufficient reason to provide so many different versions of every package. I don't think this is a lack of vision either - in most cases there really wouldn't be any noteworthy difference between an x86_64-generic and an x86_64-processor-specific package. There are a limited number of cases where it would even be worth considering building your own from ABS just for this optimization - it certainly doesn't seem worth the added maintenance costs of dozens of extra subdirectories in the repos.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
Pages: 1