Rebuild Slackware (LinkedIn project)
An interesting project, here
|
Thanks, but I won't register to Linkedin for that.
Please post a link to a publicly available web page if any. |
Quote:
While we wait for the answer I will copy and past his post: Quote:
|
<non constructive>Recompiling my 1111 packages to get a performance increase I'm no sure that it I will even notice is not on the top of my TODO list</non constructive>
But that could interest some, and probably some slackers did that already. Maybe they could post here how they did it, then? |
Maybe the odd package could benefit from targeted recompilation, but I have to agree with Didier. A complete rebuild seems like it wouldn't give a worthwhile return on investment.
|
Tommaso ought to be running Gentoo instead.
|
While were on the subject. How safe is gcc -O3 these days. I know that it had a reputation for causing problems in the past? Is that still the case?
|
If that person were using Google+ to discuss it instead of LinkedIn, I would possibly read it. But I unsubscribed from that Slackware group on LinkedIn long ago because of all the SPAM I got in my mailbox from one of the other members promoting his books.
Anyway, looking at his "/etc/make.conf" perhaps he should have a look at the Alien's ARM project where I am modifying lots of SlackBuild scripts to read a configuration file "/etc/slackbuild/machine.conf". I use that filename and in my SlackBuild script modifications am using a variable definition block which I discussed with Pat and which has his approval (basically he changed a few things to arrive at the final design). As an example, look at http://taper.alienbase.nl/gitweb/?p=...bc200c;hb=HEAD for the new stype of SlackBuild. Eric |
It looks like the "unsafe" math optimisations are associated -Ofast, so -O3 is looking pretty tame.
|
The old style block of code dealing with $ARCH doesn't have to be anywhere near as ugly as it is: The selections in the case statement are duplicated in the if/then/elif/else blocks below it, and then there's that completely unnecessary double call to uname -m)
I use the following construct in my build scripts which is much cleaner. Code:
case "${ARCH:=$(uname -m)}" in |
I just tried march=core2 on ffmpeg and MPlayer and it appears to have doubled the cpu utilisation while playing back a vidieo, so I'll be sticking with the defaults in future.
|
Reply from Tommaso:
Quote:
|
Quote:
This is really cool! :D |
Quote:
|
Quote:
|
All times are GMT -5. The time now is 11:47 AM. |