This flag disables the code which checks whether the current instance of
firejail is running within a sandbox like LXC, chroot or firejail itself.
If we want to develop firejail inside of a sandbox, to keep the "host system"
clean of unnecessary installed dependencies and changes to the system,
we might want to force firejail to run normally, so that we can test different
profiles inside of the sandbox. This is only meant for people who are working
on the firejail code, not someone attempting to run firejail inside of a
sandbox as a user, because it needs to run as root and it can escape the
sandbox easily.
Tools:
* gzip
* install
* rm
* strip
* tar
For the programs not checked in configure.ac:
From the manual of GNU Autoconf (version 2.71):
> If you use `AC_PROG_INSTALL`, you must include `install-sh` in your
> distribution
So set `install` just in the Makefile. Use `$(RM)` to ensure that `-f`
is always used and to make it easier to spot when `-r` is used.
See commit 93d623fdf ("build: allow overriding certain tools",
2024-02-23) / PR #6222.
The warning is being produced on Arch since pacman 6.1, which changed
`-D_FORTIFY_SOURCE=2` to `-D_FORTIFY_SOURCE=3` in CFLAGS in
makepkg.conf:
$ pacman -Q gcc pacman
gcc 13.2.1-5
pacman 6.1.0-3
$ makepkg
[...]
make -C src/lib
gcc [...] -D_FORTIFY_SOURCE=2 [...] -Wp,-D_FORTIFY_SOURCE=3 [...] -c ../../src/lib/common.c -o ../../src/lib/common.o
<command-line>: warning: "_FORTIFY_SOURCE" redefined
<command-line>: note: this is the location of the previous definition
To fix this, only add `-D_FORTIFY_SOURCE` to EXTRA_CFLAGS if it does not
cause any warnings with CFLAGS and CPPFLAGS during compilation.
The effect remains the same: The build system still defines the macro by
default (if there are no warnings) and the user/distribution can still
override it through CFLAGS/CPPFLAGS.
Fixes#6282.
Reported-by: @glitsj16
Allow overriding the following tools at configure-time and build-time:
* codespell
* cppcheck
* gawk
* scan-build
For example, instead of hardcoding `gawk`, enable overriding it at
configure-time with:
./configure GAWK=/path/to/gawk
To override it for a single `make` invocation:
make GAWK=/path/to/gawk
Also, add default values for the programs that are not found (rather
than leaving the variables empty), to make error messages clearer when
trying to run them:
$ make CPPCHECK= cppcheck-old
[...]
force --error-exitcode=1 --enable=warning,performance .
make: force: No such file or directory
$ make CPPCHECK=cppcheck cppcheck-old
[...]
cppcheck --force --error-exitcode=1 --enable=warning,performance .
make: cppcheck: No such file or directory
Instead of manually specifying which source files depend on which
headers, use compiler flags to automatically generate depfiles (.d),
which declare the correct header (make) dependencies for each source
file (.c).
Use `-MMD` (which ignores system headers) to generate the dependencies
and `-MP` to prevent make from complaining when a header file is removed
while it is listed as a dependency in a depfile.
If depfiles exist, just include them. If not, make each object file
(.o) unconditionally depend on all header files in its source directory
and in src/include, to ensure that rebuilds are done when needed. The
latter case applies to the first build after `make clean` (which would
build everything anyway) and when the compiler does not support
generating depfiles.
Note that both gcc and clang have supported these options for a long
time.
Misc: This depends on the changes from commit 5b1bd33c7 ("build: use
full paths on compile/link targets", 2023-07-02) / PR #6158 to avoid
issues with make dependency tracking.
With this, CFLAGS and CPPFLAGS are used when compiling and LDFLAGS when
linking, just like in the built-in GNU make rules. From `make -p`:
COMPILE.c = $(CC) $(CFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c
LINK.c = $(CC) $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH)
LINK.o = $(CC) $(LDFLAGS) $(TARGET_ARCH)
Note: It is unclear where the `INCLUDE` variable comes from; it is not
documented in autoconf nor GNU make and automake (which itself is not
used in this repository) only mentions `INCLUDES`:
`INCLUDES`
This does the same job as `AM_CPPFLAGS` (or any per-target
`_CPPFLAGS` variable if it is used). It is an older name for
the same functionality. This variable is deprecated; we
suggest using `AM_CPPFLAGS` and per-target `_CPPFLAGS` instead.
Environment: automake 1.16.5-2 and GNU make 4.4.1 on Artix Linux.
See also commit 671c3f249 ("build: actually set LDFLAGS and LIBS in
makefiles", 2022-11-30) / PR #5504.
Based on 5315 by ChrysoliteAzalea.
It is based on the same underlying structure, but with a lot of
refactoring/simplification and with bugfixes and improvements.
Co-authored-by: Kelvin M. Klann <kmk3.code@protonmail.com>
Co-authored-by: Азалия Смарагдова <charming.flurry@yandex.ru>
The -mretpoline flag is not documented in the current versions of gcc
and clang and it is what causes scan-build to fail:
$ ./configure CC=clang | grep retpoline
checking whether C compiler accepts -mretpoline... yes
EXTRA_CFLAGS: -mretpoline -fstack-clash-protection -fstack-protector-strong
$ scan-build --status-bugs make
scan-build: Using '/usr/bin/clang-15' for static analysis
make -C src/lib
make[1]: Entering directory '/tmp/firejail/src/lib'
/usr/bin/../lib/clang/ccc-analyzer [...] -mretpoline [...] -c common.c -o common.o
gcc: error: unrecognized command-line option ‘-mretpoline’
make[1]: *** [../../src/prog.mk:16: common.o] Error 1
make[1]: Leaving directory '/tmp/firejail/src/lib'
make: *** [Makefile:59: src/lib] Error 2
scan-build: Analysis run complete.
scan-build: Removing directory '/tmp/scan-build-[...]' because it contains no reports.
scan-build: No bugs found.
Environment: clang 15.0.7-9 and gcc 13.1.1-1 on Artix Linux.
Note: NO_EXTRA_CFLAGS was added to work around this issue by causing all
of the flags in EXTRA_CFLAGS to be ignored.
Note2: -mretpoline was added on commit 4a99c8aa2 ("spectre support for
clang compiler", 2018-03-30) and NO_EXTRA_CFLAGS was added on commit
490918c35 ("fix make scan-build for debian 10 and arch", 2019-07-22).
See also commit 2c64d1fdd ("use AX_CHECK_COMPILE_FLAG to check for
spectre flags", 2019-06-21).
Closes#5509.
Kind of relates to #2661.
LIBS is the variable that Autoconf uses to put library flags. From the
manual of GNU Autoconf (version 2.69):
> -- Variable: LDFLAGS
>
> [...]
>
> This variable's contents should contain options like '-s' and '-L'
> that affect only the behavior of the linker. Please see the
> explanation of 'CFLAGS' for what you can do if an option also
> affects other phases of the compiler.
>
> Don't use this variable to pass library names ('-l') to the linker;
> use 'LIBS' instead.
>
> -- Variable: LIBS
>
> '-l' options to pass to the linker. The default value is empty,
> but some Autoconf macros may prepend extra libraries to this
> variable if those libraries are found and provide necessary
> functions, see *note Libraries::. 'configure' uses this variable
> when linking programs to test for C, C++, Objective C, Objective
> C++, Fortran, and Go features.
Both variables are used inside on src/prog.mk and src/so.mk, but they
are not currently defined in any makefile, so their values cannot be
substituted by ./configure.
This means that the variables can be set when running make (such as with
`make LDFLAGS=-Lfoo`), but changing them in configure.ac has no effect.
The same applies when trying to set them when running ./configure (such
as with `./configure LDFLAGS=-Lfoo`).
Instead of binding them together with conditionals in a single line,
split shell commands into multiple lines to make them more readable.
Note that for the macro arguments in question, the content inside []
quotes is output literally into ./configure, so the commands can be
written as if they were in a shell script directly (save for any special
characters/tokens in Autoconf).
Misc: Relates to commit 2c64d1fdd ("use AX_CHECK_COMPILE_FLAG to check
for spectre flags", 2019-06-21).
Added on commit d1acb31c9 ("compile time: enable LTS", 2021-02-28).
Note: Do not print a preceding blank line because one is already printed
right before the warning message, right after the items on "Features:".
Example of the resulting warning message:
$ autoconf && ./configure
[...]
configure: creating ./config.status
config.status: creating config.mk
config.status: creating config.sh
Compile options:
[...]
prefix: /usr/local
sysconfdir: ${prefix}/etc
Spectre compiler patch: yes
Features:
[...]
SELinux labeling support:
user namespace: -DHAVE_USERNS
X11 sandboxing support: -DHAVE_X11
*********************************************************
* Warning: Long-term support (LTS) was enabled! *
* Most compile-time options have been rewritten! *
*********************************************************
$
Consider the current code:
AS_IF([test "x$enable_lts" = "xyes"], [
# ...
HAVE_CONTRIB_INSTALL="no",
Result of testing the value:
$ HAVE_CONTRIB_INSTALL="no",
$ printf '%s\n' "$HAVE_CONTRIB_INSTALL"
no,
$ test "x$HAVE_CONTRIB_INSTALL" = "xno" &&
echo equal || echo 'not equal'
not equal
This means that whenever HAVE_LTS is enabled, HAVE_CONTRIB_INSTALL is
always considered enabled when testing against "no".
But luckily, in the current code the latter variable is only tested
against "yes", so nothing should be affected:
$ git grep HAVE_CONTRIB_INSTALL |
grep -v -e '^configure:' -e '^configure.ac:'
Makefile:ifeq ($(HAVE_CONTRIB_INSTALL),yes)
config.mk.in:HAVE_CONTRIB_INSTALL=@HAVE_CONTRIB_INSTALL@
Added on commit d1acb31c9 ("compile time: enable LTS", 2021-02-28).
This reverts commit 54cb3e741e, reversing
changes made to 97b1e02d5f.
There were many issues and requests for changes raised in the pull
request (both code-wise and design-wise) and most of them are still
unresolved[1].
[1] https://github.com/netblue30/firejail/pull/5315
Configure summary: autoconf essentially only parses configure.ac and
generates the configure script (that is, the "./configure" shell
script). The latter is what actually checks what is available on the
system and internally sets the value of the output variables. It then,
for every filename foo in AC_CONFIG_FILES (and for every output variable
name BAR in AC_SUBST), reads foo.in, replaces every occurrence of
`@BAR@` with the value of the shell variable `$BAR` and generates the
file foo from the result. After this, configure is finished and `make`
could be executed to start the build.
Now that (as of #5140) all output variables are only defined on
config.mk.in and on config.sh.in, there is no need to generate any
makefile nor any other mkfile or shell script at configure time. So
rename every "Makefile.in" to "Makefile", mkdeb.sh.in to mkdeb.sh,
src/common.mk.in to src/common.mk and leave just config.mk and config.sh
as the files to be generated at configure time.
This allows editing and committing all makefiles directly, without
potentially having to run ./configure in between.
Commands used to rename the makefiles:
$ git ls-files -z -- '*Makefile.in' | xargs -0 -I '{}' sh -c \
"git mv '{}' \"\$(dirname '{}')/Makefile\""
Additionally, from my (rudimentary) testing, this commit reduces the
time it takes to run ./configure by about 20~25% compared to commit
72ece92ea ("Transmission fixes: drop private-lib (#5213)", 2022-06-22).
Environment: dash 0.5.11.5-1, gcc 12.1.0-2, Artix Linux, ext4 on an HDD.
Commands used for benchmarking each commit:
$ : >time_configure && ./configure && make distclean &&
for i in $(seq 1 10); do
{ time -p ./configure; } 2>>time_configure; done
$ grep real time_configure |
awk '{ total += $2 } END { print total/NR }'
Currently, the configure-time variables (that is, the ones that assign
to placeholders, such as "@HAVE_MAN@", which are set/replaced at
configure-time) are defined on multiple files (such as on Makefile.in
and on common.mk.in).
To avoid duplication, centralize these variables on a single file
(config.mk.in) and replace all of the other definitions of them with an
include of config.mk.
An output message and some whitespace were changed on commit 9903aaa9c
("rel 0.9.68rc1 testing", 2022-01-18).
Environment: autoconf 2.69 (with the runstatedir patch) on Artix Linux
