By default autoconf expands `@localstatedir@` to `/var`.
`VARDIR` was first added on commit a627071b3 ("intrusion detection
system", 2021-07-28) and is only used in src/firejail/ids.c.
This is a follow-up to commit 5b4524a74 ("build: use TARNAME in
SYSCONFDIR/VARDIR (#6713)", 2025-04-19).
This reverts commit 5c6fa6ab58.
The commit in question causes `HAVE_SANDBOX_CHECK` to always be unset
(instead of only when `--disable-sandbox-check` is used), as its value
was being passed to the compiler through `MANFLAGS`. Move the macro
back into `MANFLAGS` for simplicity.
Also, using `--disable-sandbox-check` breaks the tests and thus also
breaks CI (see #6619).
Relates to #6592.
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.
This makes the compile commands clearer when building in parallel (with
`make -j`) and ensures that `__FILE__` includes the full build-time path
(relative to the root of the repository) whenever it is referenced, such
as in failed assert() messages (currently the full path is only shown in
errExit() messages). Example:
Before:
firejail: main.c💯 main: Assertion `1 == 2' failed.
Error src/firecfg/main.c💯 main: malloc: Cannot allocate memory
After:
firejail: ../../src/firejail/main.c💯 main: Assertion `1 == 2' failed.
Error ../../src/firecfg/main.c💯 main: malloc: Cannot allocate memory
Commands used to search and replace:
$ git grep -Ilz '^MOD_DIR =' -- '*Makefile' | xargs -0 -I '{}' \
sh -c "printf '%s\n' \"\$(sed -E \
-e 's|^MOD_DIR = src/(.*)|MOD = \\1\\nMOD_DIR = \$(ROOT)/src/\$(MOD)|' \
-e 's:^(PROG|SO) = [^.]+(\.so)?$:\\1 = \$(MOD_DIR)/\$(MOD)\2:' \
'{}')\" >'{}'"
$ git grep -Ilz '^HDRS :=' -- '*.mk' | xargs -0 -I '{}' \
sh -c "printf '%s\n' \"\$(sed -E \
-e 's|wildcard (\*\..)|wildcard \$(MOD_DIR)/\\1|' '{}')\" >'{}'"
Note: config.mk.in, src/fnettrace/Makefile and src/include/common.h were
edited manually.
This is a follow-up to #5871.
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>
Changes:
* Move msg to the end of errExit (right before perror(3p))
* Include the full file path (within the repository)
* Add "()" to function name for clarity
Before:
Error malloc: main.c:123 main: Cannot allocate memory
After:
Error src/firejail/main.c:123 main(): malloc: Cannot allocate memory
Note: This clarifies which is the exact file that the error message
comes from, as there are many source files with the same name. For
example:
$ git ls-files 'src/*/main.c' | wc -l
20
To reduce the amount of boilerplate in the makefiles.
This amends commit 9789c263a ("build: disable all built-in implicit make
rules", 2023-06-21) / PR #5864.
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.
From the manual of GNU Automake (version 1.16.5)[1] [2]:
> 3.6 Variables reserved for the user
>
> Some `Makefile` variables are reserved by the GNU Coding Standards for
> the use of the "user"—the person building the package. For instance,
> `CFLAGS` is one such variable.
>
> Sometimes package developers are tempted to set user variables such
> as `CFLAGS` because it appears to make their job easier. However, the
> package itself should never set a user variable, particularly not to
> include switches that are required for proper compilation of the
> package. Since these variables are documented as being for the
> package builder, that person rightfully expects to be able to override
> any of these variables at build time.
>
> To get around this problem, Automake introduces an
> automake-specific shadow variable for each user flag variable.
> (Shadow variables are not introduced for variables like `CC`, where
> they would make no sense.) The shadow variable is named by prepending
> `AM_` to the user variable's name. For instance, the shadow variable
> for `YFLAGS` is `AM_YFLAGS`. The package maintainer—that is, the
> author(s) of the `Makefile.am` and `configure.ac` files—may adjust
> these shadow variables however necessary.
>
> Note Flag Variables Ordering::, for more discussion about these
> variables and how they interact with per-target variables.
See also the description of CFLAGS in the GNU Autoconf manual[3].
Note: We do not use automake (save for aclocal) nor generally follow the
GNU Coding Standards, but the concept still applies. Also, the closest
analogous in the project to the `AM_` prefix would currently likely be
`EXTRA_`.
[1] https://www.gnu.org/software/automake/manual/1.16.5/html_node/User-Variables.html
[2] https://www.gnu.org/software/automake/manual/1.16.5/html_node/Flag-Variables-Ordering.html
[3] https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Preset-Output-Variables.html
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`).
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
That expands to `@PACKAGE_TARNAME@`, similar to the existing
PACKAGE_TARNAME variable.
To make it easier to use (and read) and to be more consistent with the
surrounding variables (NAME and VERSION).
Note that the original PACKAGE_TARNAME is still needed, as by default
(on autoconf v2.69) `docdir=@docdir@` in config.mk.in expands to the
following in config.mk:
docdir=${datarootdir}/doc/${PACKAGE_TARNAME}
To note on the output files that they are generated and to clarify how
they are generated.
From the manual of GNU Autoconf (version 2.69):
> -- Variable: configure_input
> A comment saying that the file was generated automatically by
> 'configure' and giving the name of the input file. 'AC_OUTPUT'
> adds a comment line containing this variable to the top of every
> makefile it creates. For other files, you should reference this
> variable in a comment at the top of each input file. For
> example, an input shell script should begin like this:
>
> #!/bin/sh
> # @configure_input@
>
> The presence of that line also reminds people editing the file
> that it needs to be processed by 'configure' in order to be used.
Resulting output on config.mk:
# config.mk. Generated from config.mk.in by configure.
Relates to #5140.
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.
