How to set SLACKBUILD CFLAGS / CXXFLAGS / QMAKE C/CXX flags globally?
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.
How to set SLACKBUILD CFLAGS / CXXFLAGS / QMAKE C/CXX flags globally?
Hello everyone.
I guess this is an odd first question and an odd first thread here.
I apologize if this question has been asked before, but almost everything I've found are age old threads, and I think, when it comes to the compilation flags the SLACKBUILD format has probably changed since then?
Anyway, what I wanted to ask was can you and if yes how do you set CFLAGS or CXXFLAGS (C++ flags), QMAKE C/CXX FLAGS (QMAKE_CFLAGS_RELEASE and QMAKE_CXXFLAGS_RELEASE) globally? (so, any of them)
I'm most interested if you can set CFLAGS and CXXFLAGS globally to overwrite those default ones in slackbuilds, so that I don't have to edit each slackbuild manually for every package.
I'm asking this since I've used Arch Linux for a long time and I'm used to specifying compilation flags for AUR scripts/PKGBUILDs and the like. I would like to specify them at least for some packages and recompile packages to optimize them for Atom cpu in my laptop (I've installed the 32bit version of Slackware. So, I'd use sse up to sse4.2 and -mfpmath=sse and some other optimizations). Also, the MAKEOPTS="-j3" come to mind
I want to compile packages with options that are enabled by -march=native, so I'd create packages which run only on my/this specific Atom cpu and favour it's capabilities.
Also, Slackware is probably the most responsive Linux distro I've tried on this laptop.
I think /etc/profile.d is the place to set environment variables globaly (eg for all users)
There, any script with .sh extension and that has executable permission will be sourced (if you use bourne type shell or .csh for c shells)
Each SlackBuild script is inherently standalone and unique, but almost none of the SlackBuild scripts from Slackware itself or SlackBuilds.org will pay any attention if you set any compiler flags externally via environment variables. A few SlackBuilds have carefully chosen hardcoded options, but most are hardcoded with '-O2 -march=i486 -mtune=i686' on 32 bit.
This question has come up occasionally in the past, but nobody has ever made a case with proper benchmarks that diddling compiler flags would make a worthwhile difference beyond placebo. You'll get far more gain from going 64 bit than by trying to rice 32 bits with -march=native, and I'm not sure if the fancier sse stuff is even compatible with -m32. 32 bit support in Slackware will probably be around for many years to come, but I doubt anybody will be bothered changing anything at this time to optimise it even if you showed a small benefit.
MAKEOPTS is a different matter. It is a Gentoo specific environment variable. *Nothing* other than Gentoo's tools recognises it. The standard name is MAKEFLAGS, and you can use MAKEFLAGS with the vast majority of SlackBuilds.org scripts. I'd recommend using '-l' in addition to '-j', for example export MAKEFLAGS='-j6 -l3'
While I agree with 55020 that there is not much benefit if I was going to attempt this I would make a wrapper script that would copy a slackbuild, sed the appropriate $SLKCFLAGS variable (Not all scripts use this variable) and then executes the new edited script.
AFAIK, there are only some ways you could achieve what you're looking after when using SlackBuilds and all these imply some manual checking and editing work.
1. Manually edit the SlackBuild script and add what you want to the $SLKCFLAGS variable. If there are other FLAGS that are not covered in the SlackBuild and the package configure script supports (manually check with configure --help), you can define them as environmental variables either before running the SlackBuild script or within the script itself, just before the section where the script executes the package configure script, with (for example):
export C_INCLUDE_PATH=
LDFLAGS=""
2. Put a break in the SlackBuild script just after it executes the package configure script (and before issuing make) and manually edit the resulted Makefile. For example, look in the Makefile for the field "CFLAGS =" and edit add/remove your flags. This works well when the source package has only one central Makefile, if there are Makefiles in every (sub)directory of the source base of the package - then you have a lot of work - editing each one individually. Finally, once you're done editing, resume the SlackBuild script execution and enjoy your "platform optimized" package.
@qwxy
The previous hints were for a non-invasive surgery. If you believe that you're skilled enough / have plenty of time, you could recompile gcc and change the default compiler flags, then you'll get your desired global effect.
To check the actual ones, run:
as mentioned above, each SlackBuild script is inherently standalone and unique
but
usually slack build files contain boilerplate like
and some places make it even a requirement to do so, like SBO who will reject your build if it does not use the standard build template.
Code:
if [ -z "$ARCH" ]; then
case "$( uname -m )" in
i?86) ARCH=i486 ;;
arm*) ARCH=arm ;;
*) ARCH=$( uname -m ) ;;
esac
fi
and than
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"
else
SLKCFLAGS="-O2"
LIBDIRSUFFIX=""
fi
and than
Code:
CFLAGS="$SLKCFLAGS" \
CXXFLAGS="$SLKCFLAGS" \
followed buy configure, cmake whatever
you see what happens?
you can set whatever global build flags ever, they will be ignored and overwritten by the usual and standard slack builds
it is in the else case of the second code block, otherwise your special ARCH could fix this
this means, whatever you do , your flags will be kindly ignored, one of the reasons why I had my own builds for many packages over many years but this became to time intensive.
all this redundant boilerplate in each Slackbuild file is there to give you exactly no options :-)
sorry for mention this reality.
and this is Slackware, things to not change that easy, not even if something is so suboptimal like this, missing multilib compiler and packages, or PAM support.
So the old information you found is very probably still valid.
Eric did, when I remember correct, some years ago, a proposal for a more flexible way of getting global compiler flags, through including a global spec file, but this idea never seen the light. (sorry when I remember false Eric, pls correct if so)
I think Salix has an alternative, and more arch way, of building slack packages, and once I have seen something, I think from ivaldi, that looked also arch like.
I think Salix has an alternative, and more arch way, of building slack packages, and once I have seen something
Yes. See e.g. a slkbuild package here and the source directory there. That's what I use when I have to make a new package.
After installation, read "man slkbuild" and "man SLKBUILD". Templates are stored in /etc/slkbuild, you can edit them and make your own.
PS it is recommended to use fakeroot when running slkbuild. That's also what I do when testing my SlackBuilds just to avoid nasty consequences of wrong paths on the host's main directories. Yes, I make mistakes...
Last edited by Didier Spaier; 01-10-2018 at 06:36 AM.
Reason: PS added.
Eric did, when I remember correct, some years ago, a proposal for a more flexible way of getting global compiler flags, through including a global spec file, but this idea never seen the light. (sorry when I remember false Eric, pls correct if so)
When I worked on an hard-float ARM port for Slackware I wanted to stick to the concept of using one single source tree for all ARCH'es (the armedslack aka slackwarearm port maintained by MoZes does not use unmodified Slackware build scripts), so I proposed the following:
Code:
# You can use your own private machine.conf file to overrule machine defaults:
if [ -e $SRCDIR/machine.conf ]; then
. $SRCDIR/machine.conf
elif [ -e /etc/slackbuild/machine.conf ]; then
. /etc/slackbuild/machine.conf
else
# Automatically determine the architecture we're building on:
if [ -z "$ARCH" ]; then
case "$(uname -m)" in
i?86) ARCH=i586 ;;
arm*) readelf /usr/bin/file -A | egrep -q "Tag_CPU.*[4,5]" && ARCH=arm ||
ARCH=armv7hl ;;
# Unless $ARCH is already set, use uname -m for all other archs:
*) ARCH=$(uname -m) ;;
esac
export ARCH
fi
# Set CFLAGS/CXXFLAGS and LIBDIRSUFFIX:
case "$ARCH" in
i?86) SLKCFLAGS="-O2 -march=${ARCH} -mtune=i686"
SLKLDFLAGS=""; LIBDIRSUFFIX=""
;;
x86_64) SLKCFLAGS="-O2 -fPIC"
SLKLDFLAGS="-L/usr/lib64"; LIBDIRSUFFIX="64"
;;
armv7hl) SLKCFLAGS="-O2 -march=armv7-a -mfpu=vfpv3-d16"
SLKLDFLAGS=""; LIBDIRSUFFIX=""
;;
*) SLKCFLAGS=${SLKCFLAGS:-"-O2"}
SLKLDFLAGS=${SLKLDFLAGS:-""}; LIBDIRSUFFIX=${LIBDIRSUFFIX:-""}
;;
esac
fi
case "$ARCH" in
arm*) TARGET=$ARCH-slackware-linux-gnueabi ;;
*) TARGET=$ARCH-slackware-linux ;;
esac
It was not adopted in full, unfortunately. You'll find this block of code in very few official Slackware build scripts (samba and tigervnc).
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.