The link points to a dead resource.
Replace it with the correct link.
Signed-off-by: Ariel Otilibili <ariel.otilibili-anieli@eurecom.fr>
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
It was introduced between libcap-1.97 and libcap-2.00 but never
actually referenced in the build tree. Thanks to Ross Burton for
pointing this out!
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
This addresses the following bug:
https://bugzilla.kernel.org/show_bug.cgi?id=219456
insofar as it eliminates the need for -wrap=pthread_create
linkage. Mostly, code that uses -lpsx functions can simply
link with -lpsx now. However, for legacy reasons the library
still works when linked wrapped or with the new content of
the libpsx.pc file:
-Wl,--no-as-needed -Wl,--whole-archive -lpsx -Wl,--no-whole-archive -Wl,--as-needed -lpthread
These last options are required for getting -lcap to act at a
consistent process level and not a thread level.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
* GNU grep 3.8 considers `egrep` and `fgrep` obsolescent and throws warnings:
./mkcapshdoc.sh > capshdoc.c.cf
fgrep: warning: fgrep is obsolescent; using /bin/grep -F
fgrep: warning: fgrep is obsolescent; using /bin/grep -F
fgrep: warning: fgrep is obsolescent; using /bin/grep -F
fgrep: warning: fgrep is obsolescent; using /bin/grep -F
[...]
https://lists.gnu.org/archive/html/info-gnu/2022-09/msg00001.html
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
I've upgraded one of my systems to Fedora 35 and I found trimming
the headers in this way made the three compilations of libcap, used
by `make distcheck`, work with standard Fedora 35 compiler packages.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
David Seifert at Gentoo made a request to not require perl for
the libcap build since their distribution wants to build it prior
to building perl and so requiring it requires they maintain some
extra patches.
We previously introduced the need for perl in response to some
apparent incompatibilities between various versions of sed:
https://git.kernel.org/pub/scm/libs/libcap/libcap.git/commit/?id=9494a1fab59ac0b6e4f0bfc536fa482c6d6490b6
However, it has been 13 years since that time so we're optimistic
those problems are no longer present for anyone and we've also
added a make variable abstraction in case some builder wants to
override their system default 'sed' as make BUILD_SED=... etc.
We've also done something similar with make uses of grep, egrep
and fgrep.
Finally, for make variable naming consistency, we've replaced use
of BUILD_GPERF with USE_GPERF. Since folk may be using BUILD_GPERF
in their package building scripts, we error out if it is set.
The expectation is that people will update their package defs.
(Eventually, we plan to reuse BUILD_GPERF as an alias for 'gperf'.)
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
I've been looking at reasons packagers are not building the Go binaries
and found this with respect to RPMs:
https://github.com/rpm-software-management/rpm/issues/367
There has been no easy way to inject the otherwise unneeded workaround:
-ldflags=-linkmode=external for building (which, strangely, generates
some sort of warning and gratuitously links glibc to an otherwise
static build), but seems to work.
Until RPM supports Go's native '.note.go.buildid', and RPM requires
'.note.gnu.build-id' on binaries, I guess this can work around it:
GO_BUILD_FLAGS='-ldflags=-linkmode=external'
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Noticed that we weren't applying the same amount of flag discipline
to local BUILD_* tool rules. Fixing that, I see we've been carrying
a source code issue in libcap/_makenames.c for a while. (FIXED).
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Not sure exactly what is causing the build server to fail (can't
reproduce yet), but add some extra padding to a calloc and also
some test debugging printf()s.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
These allow overriding of the sbin target directory with
make sbindir=xxx
or
make sbin=xxx
We've recently made some CPPFLAGS changes, so I'm not going to
disturb those further this iteration.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
I've yet to understand why this is needed. But, apparently, folk
feel strongly that there is a reason one might want to force it
one way or another. If you don't care one way or the other, let
the Makefiles figure out something that works.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Some system libraries support being run as regular executables.
Now that I have figured out how to do it, add support for libcap.so
and libpsx.so to print some information and exit.
Note, I've explained how most of this stuff works in this answer:
https://stackoverflow.com/a/68339111/14760867
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
