| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Added on commit 4e8244fb8 ("makefiles: deduplicate configure-time vars
into new config.mk.in", 2022-05-04) / PR #5140.
|
|
|
|
|
|
|
| |
Below HAVE_PRIVATE_HOME.
This amends commit dbbdca902 ("config.mk.in: respect configure.ac usage
order", 2023-03-13) / PR #5732.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 54cb3e741e972c754e595d56de0bca0792299f83, reversing
changes made to 97b1e02d5f4dca4261dc9928f8a5ebf8966682d7.
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 match other similar variables, such as datarootdir and mandir.
|
|
|
|
|
|
|
| |
Move up the variables that are defined in the `AC_INIT` call on
configure.ac.
And put VERSION last, to match the usual `$(NAME)-$(VERSION)` usage.
|
|
|
|
| |
Move it to the bottom, near other compilation-related flags.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|