This way, update builds track shlib major bumps correctly.
For example, suppose you had built Heimdal's libkrb5.so.27 and
libgssapi.so.11 linked against it, and then you updated past the recent
shlib major bump raising them to libkrb5.so.28 and libgssapi.so.12.
Without this change, the build will make the following sequence of
targets (interleaved with some others):
1. make dependall in libkrb5
2. make dependall in libgssapi
3. make install in libkrb5
4. make install in libgssapi
The existing .WAIT tags in SUBDIR ensure that (1) happens before (2)
and (3) happens before (4). Unfortunately, this sequence is wrong,
because it will produce the following effect:
1. make dependall in libkrb5 builds libkrb5.so.28
2. make dependall in libgssapi builds libgssapi.so.12, linked against
libkrb5.so.27
3. make install in libkrb5 installs libkrb5.so.28
4. make install in libgssapi installs libgssapi.so.12
Why the out-of-date libkrb5.so.27 in step (2)? Because we just pass
-L${DESTDIR}/usr/lib -lkrb5 to the linker (or the equivalent with
--sysroot and implied -L/usr/lib), and ${DESTDIR}/usr/lib still has
only libkrb5.so.27 by the time of step (2), not libkrb5.so.28.
Now any applications that link against libkrb5.so _and_ libgssapi.so
will get libkrb5.so.28 and libgssapi.so.12 -- but transitively, via
libgssapi.so.12, they will also get libkrb5.so.27, which is a recipe
for disaster.
Splicing the Heimdal library subdirectories into lib/Makefile, as
this does, ensures that we run make dependall _and_ make install in
libkrb5 _before_ make dependall in libgssapi, giving the following
correct sequence:
1. make dependall in libkrb5 builds libkrb5.so.28
2. make install in libkrb5 installs libkrb5.so.28
3. make dependall in libgssapi builds libgssapi.so.12, linked against
libkrb5.so.28
4. make install in libgssapi installs libgssapi.so.12
Note that LIBDPLIBS isn't enough here, as implemented. LIBDPLIBS
ensures that the incremental build will remake libgssapi.so. But it
doesn't ensure that the new libkrb5.so.28 is available before then,
so it doesn't prevent this problem.
We use the same mechanism for crypto/external/bsd/openssl/lib
already; this just extends it to other external library collections.
As an alternative, in principle perhaps we could teach LIBDPLIBS to
ensure that libkrb5.so comes out of the libkrb5 objdir, and not out
of ${DESTDIR}/usr/lib. But that requires some work to make happen,
and make it reliable, whereas this approach we've already confirmed
works without other adverse consequences (besides leaving
grody-looking mechanism lying around) for the libcrypto major bump
already. We need to get this pulled up to the branch so all the
other major bumps it required are handled correctly by update builds.
XXX pullup-10
Apply upstream change
e8021f3b37
(Only differences to upstream are "meta-data" is spelled consistently
with the rest of the project documentation and the date.)
Use ${CC_WNO_MAYBE_UNINITIALIZED} instead of
the older style more complex expressions.
Remove workarounds if they were for a specific
version of gcc < 10.
Rename compiler-warning-disable variables from
GCC_NO_warning
to
CC_WNO_warning
where warning is the full warning name as used by the compiler.
GCC_NO_IMPLICIT_FALLTHRU is CC_WNO_IMPLICIT_FALLTHROUGH
Using the convention CC_compilerflag, where compilerflag
is based on the full compiler flag name.
These had their -h option removed in the ATF 0.19 release, but these
references in the man pages weren't (mostly) removed upstream until
a later commit (that hasn't been released).
case count on the tp-start line of the output match the number of test
cases actually executed (one) so that the atf-run output is valid
input to atf-report.
into '_' to meet sh variable name rules) into a shell string processing
loop.
On my test system, this reduces the total elapsed time for the bin/sh ATF
tests from about 109 secs to about 102 (user cpu from 24.5 to 21, sys cpu
from 34 to 30) and the usr.bin/make tests elapsed time from 42.5 to 40
secs (user from a bit over 15 to a bit over 13, and sys from 16+ to 13+).
(Recorded on an AMD64 domU).
These probably exaggerate the effect, as there are a bunch of quite small
tests, which means the ATF overhead (which this change affects) is a greater
proportion of the total test time than for some other tests where most of
the time is spent actually testing.
But I am fairly confident that there will be at least some improvement.
This could be further improved by removing the cmdsub invocation method,
and instead passing the name of a variable containing the string to
normalise (with the result returned in that same var) - but that would
mean altering all the callers as well. Some other time maybe.
This logic correctly uses strncpy(3) to fully initialize a fixed-width field, and also ensures
NUL-termination on the next line as other users of the field expect.
Add -Werror=stringop-truncation to prevent build failure, when run with MKSANITIZER=yes.
Error was reported when build.sh was run with MKSANITIZER=yes flag.
Reviewed by: kamil@
i don't really understand how to remove this warning, someone else
could though, so feel free to :-)
In file included from /usr/src/external/bsd/atf/dist/tools/parser.cpp:33:0:
/usr/src/external/bsd/atf/dist/tools/parser.hpp: In member function 'tools::parser::token tools::parser::tokenizer<IS>::next() [with IS = std::basic_istream<char>]':
/usr/src/external/bsd/atf/dist/tools/parser.hpp:98:8: warning: '<anonymous>.tools::parser::token::m_line' may be used uninitialized in this function [-Wmaybe-uninitialized]
struct token {
^~~~~
this API...
While here do some markup improvements (it is amazing what one can
learn from observing a wizard at work!) (which still probably need more work.)
In particular, sh functions are not functions in the mdoc .Fn sense!
(Many places where explicit double quotes were not doing what was intended.)
atf/atf-c++/macros_test/detect_unused_tests as expected failures
when using versions of GCC where they are known to fail, with a
reference to PR toolchain/49187.
Move all the reference manuals to subdirs of /usr/share/doc/reference.
We have subdirs ref1-ref9, corresponding to man page sections 1-9.
Everything that's the reference manual for a program (sections 1, 6,
8), C interface (sections 2, 3), driver or file system (section 4),
format or configuration (section 5), or kernel internal interface
(section 9) belongs in here.
Section 7 is a little less clear: some things that might go in section
7 if they were a man page aren't really reference manuals. So I'm only
putting things in reference section 7 that are (to me) clearly
reference material, rather than e.g. tutorials, guides, FAQs, etc.
This obviously leaves some room for debate, especially without first
editing the docs with this distinction in mind, but if people hate
what I've done things can always be moved again.
Note also that while roff macro man pages traditionally go in section
7, I have put all the roff documentation (macros, tools, etc.) in one
place in reference/ref1/roff. This will make it easier to find and
also easier to edit it into some kind of coherent form.
Sigh; one more attempt. This time I'm sure I've verified that the
.pc files contain the right number and that atf-version also outputs
the right stuff... Both with a clean and non-clean obj directory.
Should fix part of the problems reported in PR bin/48624.
Same trick as with atf/test-programs: provide hand-generated Atffile and
Kyuafile files so that the helpers that we build as test programs do not
end up in them.
Reported by gson@.
Yes, attempting yet another fix at this so that the version number that
gets recorded in the pkgconfig files and inside atf-version really matches
the latest imported version. Should resolve issues where the built files
get stuck with an older version number during update builds.
This time, I'm trying the same approach I applied in the FreeBSD source
tree, which has been working fine so far across various release imports.
They are not intended to be run neither by atf-run nor Kyua, and doing so
results in test failures. The easiest way to do this for now is to just
ship custom Atffile and Kyuafile files. (This broke because with atf-0.20
we started using the auto-generated versions of these, and due to the way
bsd.test.mk works, these registered the helpers as well.)
Problem reported by martin@.
The build would break when we do not use MAKEOBJDIR* but do use OBJMACHINE.
Problem found by B Harder and fix based on patch from NONAKA Kimihiro as
posted on current-users.
- Move the majority of the common build definitions to the top-level
Makefile.inc and ensure this gets included everywhere.
- Move the bconfig.h file to the top-level directory.
- Add a statically-generated defs.h file instead of creating one
during the build. Easier to understand and less chances for things
to go wrong.
- Make sure all files using ATF_VERSION have the right dependency to
trigger a rebuild when the value changes.
- Clean up stale -I flags.
This is all mostly for simplicity reasons and to reduce the cognitive
load required to understand the build of the atf and kyua-* packages.
I have tested this with both MKKYUA=no/yes and non-clean/clean builds
so hopefully I got the details right. But if not, let me know please.
Because we now own the 'tools' subdirectory in the tree, we can yank some
of the upstream autoconf-related complexity. Start doing so by removing
defs.hpp and using the real compiler attributes where necessary.
Experimental version released on February 7th, 2014.
This is the first release without the code for the deprecated tools. If
you require such code, please fetch a copy of the 0.19 release and extract
the 'tools' directory for your own consumption.
* Removed the deprecated tools. This includes atf-config, atf-report,
atf-run and atf-version.
riastradh