Perform file stripping in parallel where possible. Hardlinks remain
processed one at a time due to reproducibility issues.
Signed-off-by: Allan McRae <allan@archlinux.org>
Handle singly and muptiply hard-linked files separately. Also collect
information on hard linked files to avoid searching the entire package
to check for hard links.
Signed-off-by: Allan McRae <allan@archlinux.org>
Add a "safe_" prefix to strip_file() and strip_lto() to indicate that
these functions are taking extra steps to ensure permissions remain
unchanged.
Signed-off-by: Allan McRae <allan@archlinux.org>
Debug symbols should only be split from finally linked ELFs, not bare
object files. We're already excluding static libraries from splitting
for a similar reason.
The `.gnu_debuglink` sections are also mishandled by LLVM's LLD, which
copies them to its output. For example, this affects Arch Linux's
`/usr/lib/Scrt1.o`.
While we're here (and it changes the code less), also strip GNU LTO data
from bare objects, again for the same reason we're removing it from
static libraries, and apply static library stripping instead of shared
library stripping.
See: https://bugs.gentoo.org/787623
When objcopy encounters an already-present section, adding the new
debuglink will fail with a warning. Remove any existing `.gnu_debuglink`
section to work around this problem.
Arch Linux's `rust` package is affected by this. Apparently when LLVM's
LLD links in `/usr/lib/Scrt1.o` it will also copy the `.gnu_debuglink`
section.
See: https://bugs.gentoo.org/787623
Using objcopy can result in file permission changes. We work around this
by using "cat" to copy the temporary output file into the target. Extract
this code into a utility function.
Signed-off-by: Allan McRae <allan@archlinux.org>
The Arch sharutils package was spewing messages about "Permission denied" when
copying source files into the debug package. This is due to the source files
having 444 permissions and being used in multiple binaries. Only copy each
source file into the debug package onces to avoid this error.
Signed-off-by: Allan McRae <allan@archlinux.org>
Guile 2.2 uses ELF format for its byte-compiled files. These are not
normal executables, and are not strippable in the normal sense.
Given these are ELF files and detected by "file" as non-stripped binaries,
it is only possible to skip these using the file path.
Fixes#73
Signed-off-by: Allan McRae <allan@archlinux.org>
.a files are not valid ELF files so we can't run objcopy nor debugedit
on them.
Rename STRIPLTO to STATICLIB to be more descriptive.
Signed-off-by: Morten Linderud <morten@linderud.pw>
Some projects might duplicate the file in multiple locations for one
reason or another. When debug packages are enabled, `makepkg` will only
strip the first occurrence of the binary and abort early on all the
other binaries.
Signed-off-by: Morten Linderud <morten@linderud.pw>
When package software with debug symbols without stripping, we should
still process the files with debugedit and include the needed source
files in the package.
Signed-off-by: Allan McRae <allan@archlinux.org>
`.o` objects used to be omitted by strip.sh due to a missing match in
the `Relocatable file` section. This patch fixes the issue by handling
`.o` objects similar to kernel modules.
fixes FS#74941
Signed-off-by: Allan McRae <allan@archlinux.org>
`${pkgbase}` was added to the wrong invocation. This ensures we are
producing correct debug packages.
Example from the package:
/usr/src/debug/pacman/pacman-6.0.2/src/pacman/callback.c
/usr/src/debug/pacman/pacman-6.0.2/src/pacman/callback.h
/usr/src/debug/pacman/pacman-6.0.2/src/pacman/check.c
/usr/src/debug/pacman/pacman-6.0.2/src/pacman/check.h
Fixes: 776b7c1e75 ("debugflags: Ensure we have unique source paths")
Signed-off-by: Morten Linderud <morten@linderud.pw>
Signed-off-by: Allan McRae <allan@archlinux.org>
The debugedit call to list all source files may include things like
build/<...>. We have been filtering out these <> files, but they can
point to the build directory which is important to be available for
relative source paths stored in the .debug files.
Signed-off-by: Allan McRae <allan@archlinux.org>
In some cases packages are built outside of a directory which contains
pkgname-pkgver, this results in source listing in debug packages having
a conflicting path like `/usr/src/debug/build/` which is not ideal.
This patch ensures we always include the pkgbase to ensure the paths are
unique.
Signed-off-by: Morten Linderud <morten@linderud.pw>
Signed-off-by: Allan McRae <allan@archlinux.org>
We use a multi step process during stripping to ensure permissions do
not get changed. However, if the initial objcopy fails, the subsequent cat
results in a blank file. Abandon early if objcopy fails.
Fixes FS#74486
Signed-off-by: Allan McRae <allan@archlinux.org>
This moves us from the fairly ugly AWK parsing line to debugedit which
originally comes out of the rpm project.
The original code has issues parsing anything that was not straight
C/C++ and languages like Rust or Go would return invalid source code
files. debugedit handles all these cases better.
Fixes FS#66755
Fixes FS#66888
Fixes FS#65677
Signed-off-by: Morten Linderud <morten@linderud.pw>
Signed-off-by: Allan McRae <allan@archlinux.org>
Binutils commit 93df3340fd5ad32f784214fc125de71811da72ff enabled readelf
to report "Position-Independent Executable" files. Fix stripping to
account for this change.
Signed-off-by: Allan McRae <allan@archlinux.org>
readelf --debug-dump sometimes reports inscrutable warnings which don't
actually affect our extraction of source filenames. For example:
readelf: Warning: There is a hole [0xd3d - 0xd89] in .debug_loc section.
Now gcc 11 seems to have dramatically increased the number of warnings:
readelf: Warning: Corrupt offset (0x0000008e) in range entry 9
[...]
readelf: Warning: Corrupt offset (0x000010f0) in range entry 250
The resulting debuginfo created by the very same toolchain works fine,
as does the list of source filenames. But the warnings are quite
noisy... send them to /dev/null since they are not actionable in the
context of getting source files
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
The current gcc build from git master give different output from
readelf:
gcc-10.2.0
$ readelf "hello" --debug-dump | grep hello
<11> DW_AT_name : (indirect string, offset: 0xbfc): hello.cpp
gcc-git
$ readelf "hello" --debug-dump | grep hello
<12> DW_AT_name : (indirect line string, offset: 0x0): hello.cpp
This causes the awk statement extracting the file name to fail as it
relied on the information being in the 8th field. Instead, extract
the information from the final field.
Fixes FS#70168
Signed-off-by: Allan McRae <allan@archlinux.org>
GCC's LTO implementation emits bytecodes into .o files it generates.
These bytecodes are _not_ considered stable from one release of GCC
to the next. There we need to strip the LTO bytecode out of any .o
(and .a) file that gets installed into the package.
Signed-off-by: Allan McRae <allan@archlinux.org>
It updates the stripped/objcopied file by creating a temp file,
chown/chmodding it, and replacing the original file. But upstream
binutils has CVE-worthy issues with this if running strip as root, and
some recent versions of strip don't play nicely with fakeroot.
Also, this has always destroyed xattrs. :/
Sidestep the issue by telling strip/objcopy to write to a temporary
file, and manually dump the contents of that back into the original
binary. Since the original binary is intact, albeit with different
contents, it retains its correct attributes in fakeroot.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
Fix typo in a comment in tidy_emptydirs().
Signed-off-by: Michael Straube <michael.straubej@gmail.com>
Signed-off-by: Allan McRae <allan@archlinux.org>
It's either a waste of work, or triggers edge cases in some packages
(like coreutils-8.31) where the source file is readonly and cp gets a
permission denied error trying to overwrite it with an identical copy of
itself.
Also while we are at it, make the variable names be something readable,
because I could barely tell what this was doing while editing it.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
zipman:
read -r protects against those evil manpages whose filenames contain
backslash escapes, (muahahaha?)
IFS= read protects against filenames with:
- leading whitespace (but no one is actually stupid enough to configure
their MAN_DIRS=() in makepkg.conf with such silly directories, *right*?)
- trailing whitespace (but likewise, no one should be stupid enough to
write an uncompressed manpage for section '1 ' or something)
Also fix several other cases where we read filenames without protecting
against surrounding whitespace, or without using null-delimited
filenames when we could trivially do so.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
An artificial symbol can be produced when requesting debugging symbols
and the compiler has inlined a function. These symbols will give
spurious results when listing source files for inclusion in debug
packages. This will ignore these symbols and avoid an error that can be
generated when creating a debug package.
Signed-off-by: Austin Lund <austin.lund@gmail.com>
Signed-off-by: Allan McRae <allan@archlinux.org>
The right-hand side of the [[ ... = ... ]] keyword is an exception to
the general rule that quoting is unnecessary with [[
This is usually not a problem, e.g. in libmakepkg, lint_one_pkgname will
already fail if pkgname has an asterisk, but it certainly doesn't hurt
to be "more proper" and go with the spec; it is more dangerous in
repo-add, which can get caught in an infinite loop instead of safely
asserting there is no package named 'foo*'.
Reported-by: Rafael Ascensão <rafa.almas@gmail.com>
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
Provide both build systems in parallel for now, to ensure that we work
out all the differences between the two. Some time from now, we'll give
up on autotools.
Meson tends to be faster and probably easier to read/maintain. On my
machine, the full meson configure+build+install takes a little under
half as long as a similar autotools-based invocation.
Building with meson is a two step process. First, configure the build:
meson build
Then, compile the project:
ninja -C build
There's some mild differences in functionality between meson and
autotools. specifically:
1) No singular update-po target. meson only generates individual
update-po targets for each textdomain (of which we have 3). To make
this easier, there's a build-aux/update-po script which finds all
update-po targets and runs them.
2) No 'make dist' equivalent. Just run 'git archive' to generate a
suitable tarball for distribution.
DW_AT_comp_dir is meant to contain the directory in which the compiler
was run
DW_AT_name contains the source file the compiler was told to use.
In the event that DW_AT_name is an absolute path, it is (obviously) not
meant to be computed relative to DW_AT_comp_dir. However, we did not
handle this correctly, and as a result tried to copy source files using
doubled-up filepaths.
The correct approach should be to use DW_AT_name on its own, in the
event that it is an absolute path.
See http://wiki.dwarfstd.org/index.php?title=Best_Practices.
This fixes debug package generation for many packages that use absolute
paths in their build systems... like CMake.
Reported-by: Jagannathan Tiruvallur Eachambadi <jagannathante@gmail.com>
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
file 5.33 introduces a new MIME type "application/x-pie-executable",
which is used for relocatable binaries. makepkg ignored these binaries
and did not attempt to strip them.
Handle the new MIME type like the old "application/x-sharedlib".
Stripping the binaries with --strip-unneeded to keep relocation
information should be the correct thing to do.
file 5.33 also misidentifies actual libraries as PIE executables, so we
didn't strip any shared libraries, either. We now work around this bug.
Signed-off-by: Jan Alexander Steffens (heftig) <jan.steffens@gmail.com>
Signed-off-by: Allan McRae <allan@archlinux.org>
Commit 8bec63bf92 attempted to switch to
using -fdebug-prefix-map to set file locations in debug packages. It
make a few mistakes...
1) Adding debug C{,XX}FLAGS only worked if DBGSRCDIR was defined in
makepkg.conf. Fix this by falling back to the default value.
2) Using -fdebug-prefix-map altered a lot of assumptions about file
locations when copying source files into debug packages. This resulted
in lots of messages of failed cp in packaging output.
Signed-off-by: Allan McRae <allan@archlinux.org>
In commit 8b0d59b83a support was added for
storing the source files of binaries in debug packages. This made use of
the debugedit program which is part of the RPM package manager, which is
not very standalone.
The same effect can be achieved using -fdebug-prefix-map, an option
accepted by both the gcc and clang compilers which modifies how the
compiler itself stores the references to the source files rather than
requiring us to later edit the produced binaries. This also removes the
dependency on external programs like debugedit.
As a result of this change, source files will only be effectively added
for programs which actually use the exported CFLAGS. This is a reasonable
tradeoff as we expect our CFLAGS to be used rather than ignored. Upstream
software which do not produce useful debug packages are expected to fix
their build systems to respect the environment CFLAGS.
As a result of this change, the routine for extracting source filenames
from binaries had to be modified to derive the source file from the
final debug location, rather than the other way around.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
In commit 8b0d59b83a support was added for
storing the source files of binaries in debug packages. Allow the user
to specify where those source files should be stored via makepkg.conf
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
Debug packages are fairly useless currently because the soucre files needed
for stepping through code etc are not packaged with them. This patch adds the
needed source files to the debug package and adjusts the debug info to look at
the /usr/src/debug/ directory for them rather than the build location. This
requires using the "debugedit" program which is provided as part of the RPM
sources.
Signed-off-by: Allan McRae <allan@archlinux.org>
We want to provide source files with debug symbol packages to allow easy
stepping through the program. This becomes difficult with split packages due
to the binaries in many of these sharing source files across packages.
There are (at least) two solutions to this problem. #1: ensure common source
files are located in the debug package for the package lowest in the dependency
chain and add dependencies to the debug packages so all require source files
are present, or #2: create one debug package for all split packages in a
PKGBUILD. The second is a more robust approach despite potentially creating
very large debug packages.
This patch creates a single $pkgbase-debug package and adds provides such that
installing $pkgname-debug will always work.
Signed-off-by: Allan McRae <allan@archlinux.org>
Debug packages are fairly useless currently because the soucre files
needed for stepping through code etc are not packaged with them. This
patch adds the needed source files to the debug package and adjusts
the debug info to look at the /usr/src/debug/ directory for them rather
than the build location. This requires using the "debugedit" program
which is provided as part of the RPM sources.
Signed-off-by: Allan McRae <allan@archlinux.org>
