-   Slackware (
-   -   How to set SLACKBUILD CFLAGS / CXXFLAGS / QMAKE C/CXX flags globally? (

qwxy 01-09-2018 04:32 PM

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.

Cheers and thanks for reading :D , I know it's long :)

keefaz 01-09-2018 05:40 PM

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)

55020 01-09-2018 09:11 PM

Hi, and welcome to LQ (and to Slackware).

Short answer, you can't.

Each SlackBuild script is inherently standalone and unique, but almost none of the SlackBuild scripts from Slackware itself or 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 scripts. I'd recommend using '-l' in addition to '-j', for example export MAKEFLAGS='-j6 -l3'

orbea 01-09-2018 09:17 PM

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.

abga 01-09-2018 10:06 PM


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):
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.

abga 01-10-2018 04:11 AM

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:

gcc -march=native -E -v - </dev/null 2>&1 | grep cc1
You might also want to tune&recompile the kernel:

a4z 01-10-2018 05:30 AM

as mentioned above, each SlackBuild script is inherently standalone and unique
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.

if [ -z "$ARCH" ]; then
  case "$( uname -m )" in
    i?86) ARCH=i486 ;;
    arm*) ARCH=arm ;;
      *) ARCH=$( uname -m ) ;;

and than


if [ "$ARCH" = "i486" ]; then
  SLKCFLAGS="-O2 -march=i486 -mtune=i686"
elif [ "$ARCH" = "i686" ]; then
  SLKCFLAGS="-O2 -march=i686 -mtune=i686"
elif [ "$ARCH" = "x86_64" ]; then

and than



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.

Didier Spaier 01-10-2018 05:50 AM


Originally Posted by a4z (Post 5804570)
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...

Alien Bob 01-10-2018 06:20 AM


Originally Posted by a4z (Post 5804570)
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:

# 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
  # 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) ;;
    export ARCH
  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"}

case "$ARCH" in
    arm*)    TARGET=$ARCH-slackware-linux-gnueabi ;;
    *)      TARGET=$ARCH-slackware-linux ;;

It was not adopted in full, unfortunately. You'll find this block of code in very few official Slackware build scripts (samba and tigervnc).

All times are GMT -5. The time now is 11:41 AM.