| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Needed for Perl 5.38
|
|
It was previously using an experimental feature that has since been dropped.
This removes the use of that feature.
|
|
|
|
Without this change the build was simply broken, if symbol versioning
was disabled for any reason, e.g. whether the compiler nor the linker
supporting it, or if disabled on purpose by the user.
Also adapt the testsuite and the CI test-matrix.
Fixes #142.
Signed-off-by: Björn Esser <besser82@fedoraproject.org>
|
|
Using `-exec` would be another option, maybe slightly simpler.
|
|
I've missed a ShellCheck's warning about `local`, which said that
`In POSIX sh, 'local' is undefined.`
|
|
The token in ::stop-commands::{token} GA workflow command has to be a
cryptographically random and secure string. Definitely not a hardcoded string
literal. See the docs for details: https://docs.github.com/en/actions/learn-github-actions/workflow-commands-for-github-actions#stopping-and-starting-workflow-commands
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This tests four configurations: (GCC, Clang) x (Valgrind, ASan+UBSan),
all with everything enabled.
|
|
Use the ‘cache’ action to save all the files created by autogen.sh,
keyed on a hash of the autotools source files, plus the version
numbers of autoconf, automake, libtool, and pkg-config. This shaves a
few seconds off all our builds, and since we’re about to go from ten
builds to more than 50, it’s worth it.
Move log dumping on test failure to an independent script that
captures config.log as well as all testsuite logs no matter where they
are found. Use “action commands” to make nice foldable sections for
each. Also add foldable sections to the output of
ci-log-dependency-versions.
|
|
ASan’s “interceptors” for crypt and crypt_r have a semantic conflict
with libxcrypt, requiring a few tests to be disabled for builds with
-fsanitize-address. See commentary in test/crypt-badargs.c for an
explanation of the conflict, and commentary in build-aux/zw_detect_asan.m4
for why a configure test is required.
This does not work around https://github.com/google/sanitizers/issues/1365
which is an unrelated problem affecting test/special-char-salt.c and
which doesn’t currently break CI.
|
|
codecov-action@v1 is deprecated due to its inextricable coupling with
Codecov’s shell-script uploader, which is also deprecated, due to its
being an unmaintainable pile of shell script. See
https://github.com/codecov/codecov-action/blob/635d4e88ad8c1f75b56277efd9ec186c3359727f/README.md#%EF%B8%8F--deprecration-of-v1 [sic]
and https://about.codecov.io/blog/introducing-codecovs-new-uploader/
for gory details.
The new uploader does not support the ‘gcov_executable‘ and
‘gcov_path_exclude‘ parameters yet, so for the time being we go back
to preprocessing the coverage data with lcov (as we were doing on
Travis).
|
|
.perlcriticrc now explicitly mentions every single policy that is
available from the policy packages we use, as either enabled or
disabled. Furthermore .perlcriticrc lists, in comments, all of the
expected policy sets and related distributions that should be
available, with version pins; this is now the canonical home for this
information.
A new ancillary script, build-aux/check-perlcritic-config, validates
that the list of policies in .perlcriticrc is 1:1 with the set of
available policies. It is run by ‘make distcheck.’ (Todo: convert to
a local perlcritic policy so that every run of perlcritic does this
validation.)
These changes will hopefully prevent future problems along the lines
of 5ad98a9dca84f064e7dc19049afbc478d7320f97 (reverted by
55880f9d2e057b83ccaf29132f01a16d7285a7a7), where two developers did
not have the same set of perlcritic policies installed and therefore
disagreed on whether a ‘no critic’ annotation was necessary. They
will also ensure that the set of perlcritic policies being tested in
CI is exactly what we expect.
The downside of this change is that .perlcriticrc is now harder to
read through and find all the policies with configuration. Better
ideas for organizing it are welcomed.
|
|
|
|
Separate the script that logs the versions of _all_ our build
dependencies from build-aux/travis-before. Run it from the Github
Actions configuration.
|
|
This is the second of two patches being landed on trunk ahead of the
complete migration from Travis CI to Github Actions; see the commit
message for 407a546a1a8477dd18d396cb6e0533032062381e for more
explanation.
This workflow may not yet achieve code coverage matching what we had
with Travis. We are only building on Linux for now, and only with a
handful of configure-time variations.
|
|
Debian has switched to use the yescrypt hashing algorithm as
the default for new user passwords, so we should add a group
for this distribution.
|
|
|
|
Add a new data member `is_strong` to the internally used structure
`struct hashfn`. This new data member indicates whether the hashing
function corresponding to the field is considered to be strong.
|
|
If you pass CFLAGS with a leading space, " " gets passed to popen and convinces
gcc to try and open a file called " ". This results in a confusing error message
like:
x86_64-pokysdk-linux-gcc: error: : No such file or directory
Avoid this by stripping empty elements out of CFLAGS.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Almost everything depends on the generated headers; the generated
headers depend on the Makefile; *most* changes to the Makefile won't
affect the contents of the generated headers. Arrange for the
timestamps of the generated headers not to change if their contents
haven't, using an idiom borrowed from GCC's Makefile.
This exposed a bug in BuildCommon.pm that caused the contents of
crypt-symbol-vers.h to change every time it was regenerated (due to
Perl’s hash randomization). Fix that too.
|
|
|
|
For a couple of different reasons it would actually be better to
implement this program in C (see extensive grumpy commentary in
the file), but that would make it the one and only thing we needed
a $(CC_FOR_BUILD) for, and it doesn’t seem worth it right now.
|
|
This introduces a new build-time requirement for Perl >=5.14.0, which
was the version shipped with Ubuntu 14.04 (Trusty).
The scripts whose language changes are:
- build-aux/compute-symver-floor (formerly inlined in configure.ac)
- build-aux/expand-selected-hashes
- build-aux/gen-crypt-h
- build-aux/gen-crypt-hashes-h
- build-aux/gen-crypt-symbol-vers-h
- build-aux/gen-libcrypt-map
A few other one-off uses of awk are also eliminated.
Using a more powerful scripting language allows us to unify the
parsers for hashes.conf and libcrypt.map.in, and simplify two
other aspects of the build:
- the four files libcrypt.minver.{hurd,kfreebsd,linux,no} are
combined into a single file libcrypt.minver
- crypt.h is now generated in a single step from crypt.h.in, and
does not depend on crypt-hashes.h
Error checking is also substantially more robust.
|
|
This is to validate that our build scripts work with our documented
minimum version of Perl (5.14). This is the newest version of Ubuntu
on which Travis supports use of perl this old.
Contra the documentation, Trusty-based build workers’ default perl is
5.18, not 5.14. Travis doesn’t support use of the `perl: VERSION`
build matrix parameter in a `language:c` build, and it doesn’t support
use of the `compiler:` parameter in a `language:perl` build.
The least terrible kludge I can come up with is to continue using
`language:c`, manually download and install the precompiled perl 5.14
binaries that Travis _would_ use for `perl:5.14`, and then manually
activate the appropriate perlbrew environment. (We can’t use
$PERLBREW_ROOT/etc/bashrc because it’s, well, a bash script,
and our build scripts are _sh_ scripts.)
There is a pretty strong argument that no one should be using
perl < 5.18 anymore: 5.18 is the oldest version with randomized
hashes, which are a critical security fix for anyone processing
untrusted input with Perl. But the input to all our Perl scripts
is our own source or object code, so that’s not an issue for us.
In fact, we could go even earlier, since we’re not actually _using_
the Unicode support that motivated my selection of 5.14 as the
minimum. Opinions solicited.
Since this means we have to have an install script again, also use it
to install perltidy and perlcritic when DISTCHECK=1, add configuration
files for both tools, and run perlcritic from the distcheck-hook.
(This doesn’t *do* anything yet, of course, since there aren’t any
Perl scripts yet.) Quibbles with my formatting and linting choices
are also solicited.
|
|
lcov filters out branch coverage data by default because it’s
expensive to analyze, but this library is small enough that it
shouldn’t be an issue.
|
|
This works kind-of the same way as the Coverity driver: we retrieve a
shell script directly from codecov.io and execute it. This is how
codecov.io currently recommends one upload coverage reports, and means
we do not need to worry about whether ‘pip’ works. In fact, we no
longer need an install script at all.
pip is removed from the cache set, and the after-success script is
moved to the script: tag so that coverage upload failures are flagged
in the Travis dashboard.
|
|
CI builds on OSX were broken in several different ways.
- Nothing we asked for via Homebrew was getting installed, because of
a bug in the xcode9.4 build image that Travis uses as its default.
This is fixed in newer build images, so bump us up to xcode12.3.
(N.B. I don’t know which versions of xcode and/or macos we *ought*
to be compiling against, I just picked the newest one.)
For more detail about the bug, see
<https://travis-ci.community/t/macos-build-fails-because-of-homebrew-bundle-unknown-command/7296>.
- The current generation of Xcode tools doesn’t support fat-binary
compilation anymore. Also, clang doesn’t wanna see --coverage on
its command line, ever. Use a more appropriate set of options for
the new toolchain.
- ‘pip install --user’ put codecov in a weird place that wasn’t on
$PATH. The easiest fix, since we’re running in a scratch virtual
machine anyway, is to install it globally.
- Don’t install things that are already installed, because Homebrew
is painfully slow. Note: Homebrew gcc *is* already installed, but
it’s broken. Including ‘gcc’ in the packages list costs 150 seconds
of wall time(!) but it does fix the problem, so we’ll deal.
|
|
Since we might not want to keep the build scripts as a combination of
sh + awk forever, move most of them to a new top-level directory and
rename them without any .sh or .awk suffixes. This directory is named
build-aux, consistent with the recommendations in the autoconf manual,
and all of the .m4 files extending autoconf move there as well.
The shell scripts in test/ remain there, so that all of the tests stay
together, and they keep their .sh suffix, because this is how Automake
knows that they are not C programs.
|
