LinuxQuestions.org - Optimization of Slackware Packages

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

- - Optimization of Slackware Packages (https://www.linuxquestions.org/questions/slackware-14/optimization-of-slackware-packages-769480/)

Optimization of Slackware Packages

Hi Forum

This is my setup :

I have these two Slackware boxes call it David and Goliath...

David is a tiny machine I use to experiment with OSes I do not know...

Crappy ATI Graphics card, slow cpu, 1GB ram...

Goliath is powerful machine, Latest Nvidia gForce, Intel Quadcore CPU, 16 GB ram...

So I have compiled from source lots of packages which I have installed w/ src2pkg or sbopkg in "David"... "David" is running ok, fast snappier than with previous OSes...

In case I find out I can build all my work apps from source in "David" I plan to switch to "Goliath"...

My Question is... :

Are my binary Slackware packages built from source in "David" still optimized to run in "Goliath"... assuming the hosting OS will be the same, of course... despite all the difference in hardware specs...?

Or Should I best rebuild them on "Goliath"...?

BRGDS

Alex

If you are using src2pkg or the default SlackBuilds, then the most the packages will be built for is i686. The packages are not actually being optimized for either machine, they are being built for generic x86 processors. Rebuilding them on the faster machine wouldn't do anything, the only difference would be that they will take less time to build.

If you want to optimize a build for a specific processor, you need to do that manually by supplying the appropriate GCC options in the SlackBuild.

Quote:

Originally Posted by MS3FGX (Post 3759075)

If you are using src2pkg or the default SlackBuilds, then the most the packages will be built for is i686. The packages are not actually being optimized for either machine, they are being built for generic x86 processors. Rebuilding them on the faster machine wouldn't do anything, the only difference would be that they will take less time to build.

If you want to optimize a build for a specific processor, you need to do that manually by supplying the appropriate GCC options in the SlackBuild.

That's note quite true. I know for a fact that the SlackBuilds from Slackbuilds.org read the uname -m variable and then select the correct architecture from that:

Code:

if [ "$ARCH" = "i486" ]; then

  SLKCFLAGS="-O2 -march=i486 -mtune=i686"

  LIBDIRSUFFIX=""

elif [ "$ARCH" = "i686" ]; then

  SLKCFLAGS="-O2 -march=i686 -mtune=i686"

  LIBDIRSUFFIX=""

elif [ "$ARCH" = "x86_64" ]; then

  SLKCFLAGS="-O2 -fPIC"

  LIBDIRSUFFIX="64"

src2pkg handles things a little differently you can (among other things) specify the architecture (from the CHANGES file for src2pkg 1.9.9):

Quote:

src2pkg now supports multi-lib and cross-compile environments.
The new command-line options -M32, -M64 or --machine= can be used
to specify the '-m??' option to gcc. For instance, when using
src2pkg to create a 32-bit program for use on a Slackware64 multi-lib
system, passing -M32 causes gcc to build for the proper machine.
The -L32, -L64 and --libdirsuffix= options control the library
paths used for compiling and packaging. Use the -L options to
set the proper options if the src2pkg defaults are not correct
for your system. With Slackware64, you should only need to use
the -M32 option in order to build 32-bit programs or libraries,
provided you have installed the necessary 32-bit environment.
The options --cc=?? and --cxx= can be used to specify which
compiler to use when using src2pkg with cross-compilers or
any other non-standard compiler.

Regards,

Quote:

Originally Posted by Lufbery (Post 3759115)

That's note quite true. I know for a fact that the SlackBuilds from Slackbuilds.org read the uname -m variable and then select the correct architecture from that:

Code:

if [ "$ARCH" = "i486" ]; then

  SLKCFLAGS="-O2 -march=i486 -mtune=i686"

  LIBDIRSUFFIX=""

elif [ "$ARCH" = "i686" ]; then

  SLKCFLAGS="-O2 -march=i686 -mtune=i686"

  LIBDIRSUFFIX=""

elif [ "$ARCH" = "x86_64" ]; then

  SLKCFLAGS="-O2 -fPIC"

  LIBDIRSUFFIX="64"

As I said, those are generic x86 options, and are not optimized for any specific processor. Code built with those options will run on any machine past the arch type selected.

Also, that code does not use uname, rather it is specified with the $ARCH variable set at the top of the Slackbuild. That is an intentional design so you CAN build non-optimized code, which is what you have to do if you intend on distributing the binaries.

Yeah, by default src2pkg sticks with the same flags as used for original slackware packages where you have: -march=i486 -mtune=i686
That makes your packages as generic as they can be.
If you want to change that, you can set the values in your src2pkg.conf file like this:
MARCH_FLAG=value
CPU_FLAG=value

Quote:

Originally Posted by MS3FGX (Post 3759150)

Also, that code does not use uname, rather it is specified with the $ARCH variable set at the top of the Slackbuild. That is an intentional design so you CAN build non-optimized code, which is what you have to do if you intend on distributing the binaries.

I'm still not sure I'm with you on this, but the fault could be mine. I think what you say is true, except for when you have a 64-bit system, which is not I686. But the Slackbuild scripts detect that. Also, the $ARCH variable at the top of the SlackBuilds is ARCH=${ARCH:-i486}, but it will choose $ARCH= "x86_64" if that's appropriate despite what's at the top of the script. My understanding from another thread is that the SlackBuilds use the uname -m variable to figure it out.

Yours in confusion,

Quote:

Originally Posted by Lufbery (Post 3759180)

The slackbuilds at slackbuilds.org have ARCH=${ARCH:-i486} because that is the default architecture the current slackbuild is building against. The syntax used for the ARCH variable as well as other variables used in the slackbuild are meant to be a default value when no extra parameters are given to the slackbuild. For instance, to use a slackbuild for x86_64 architecture then you pass that architecture to the slackbuild.

Code:

# ARCH="x86_64" ./package.SlackBuild

The other option is to predefine ARCH somewhere in your environment variables so that it always builds against that architecture. Also, I assuming you are not confusing sbopkg with manually compiling slackbuilds, because sbopkg does use the 'uname -m' option if ARCH isn't defined.

The only time I've seen uname used is when the current running kernel is being used in the slackbuild. Although, there could be other uses for uname.

Code:

KERNELVERSION=${KERNELVERSION:-$(uname -r)}

This way the slackbuild will build against the current running kernel or if KERNELVERSION is passed to the slackbuild it can be built against another kernel.

Take notice that those compiler optimizations won't make your machine suddenly fly, I mean that the difference won't be very big.

Quote:

Originally Posted by larryhaja (Post 3759218)

TAlso, I assuming you are not confusing sbopkg with manually compiling slackbuilds, because sbopkg does use the 'uname -m' option if ARCH isn't defined.

Actually, I think that is my confusion. Thanks for clearing that up.

Warm regards,

If you do want to optimize your packages, there's a program called Acovea that's supposed to give you the best CFLAGS to compile a source file with.

I've never used it myself, but it looks interesting.
http://www.coyotegulch.com/products/acovea/