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
