SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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...?
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.
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.
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
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.
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.
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.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.