- The original case of empty string ending up in a dependency is already
taken care of by commit 66a01c977e and
soname filtering. However if filtering is disabled, an an empty
(or all-whitespace) soname will produce gems like "()(64bit)" on
multilib arches, so we need to sanity check the soname itself in
elfdeps.
- The linker doesn't seem to care what kind of junk the soname contains,
we care just a little bit more as eg empty strings and whitespace
messes up other things.
AArch64 generates a relocation which must be handled similar to other
architectures. Adding this patch allows debugedit to run against the
kernel debuginfo.
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
- The message is not about basedir and destdir, and printing them
here only makes the message even more confusing than it was, eg:
canonicalization unexpectedly shrank by one character \
('/home/pmatilai/rpmbuild/BUILD/' vs '/usr/src/debug/')
- This reverts commit 1eea433d99
- A dependency on the interpreter is likely to be redundant, but
presence of PT_INTERP is a useful indication of whether a file
is executable or not: all normal dynamically linked executables
have it whether PIE DSO or "plain" executable. Some libraries
also have it but they are supposed to be really executable:
for example glibc's libc.so and libQtCore.so have it and print out
config, version etc information when executed.
- For now, we dont actually use the PT_INTERP information for anything
apart from the optional require.
- Instead of vain heuristics on DT_SONAME presence, filter out
irregular sonames from all dependencies: linkable library names generally
must contain ".so" and start with "lib" for the linker to find it at all,
anything else is an exception of one kind or another (the prime exception
of ld.so variants we handle here). This weeds out provides for most
dlopen()'ed modules etc, and filtering both provides and requires
by the same rules means we wont generate requires for things that wont be
provided. Of course this also means we can omit things that are in
DT_NEEDED, but these should be rare exceptions which the new
--no-filter-soname switch is for.
- (Private) libraries which might intentionally not have DT_SONAME
are still recorded as requires from DT_NEEDED, and there's no
way of knowing what's an internal library when generating requires.
Not faking the soname in these cases will only result in broken
requires in cases that always used to "just work".
- Change the switch to --no-fake-soname disabler instead to allow
tweaking in special cases but by default we gotta match linker
(and ELF specification) behavior, no matter how much we'd like to
use this for our own heuristics :-/
- Remember DT_SONAME in the elfInfo struct if encountered and
only add it after everything else has been processed. This doesn't
change any actual functionality for now, but gives us a single
place where to control the addition.
- Additionally document what the related DT_DEBUG test is for and
clean up the processDynamic() loop and switch-case a bit.
- This helps cutting down the number of bogus provides from dlopen()'ed
plugins and internal libraries which preferrably shouldn't have a
soname at all. Unfortunately libtool always puts in a soname even if
-module -avoid-version is used :-/
- OTOH there are broken libraries which dont have a soname even though
they should, so (we need to) allow falling back to the former behavior
of faking up a soname from the basename.
- Determine arch-specific issues by looking at the elf header instead
of compile-time #ifdefs, so we'll generate correct dependencies for
non-native elf binaries too. Currently this is just alpha which despite
being a 64bit system, never had the (64bit) markers in its dependencies.
Of course alpha has pretty much already met its mark^H^H er maker by now,
but doing the right thing is cheap... Also we'll need similar special
cases sooner or later for other archs (such as x32).
- Commit a25c3c7bac removed what was
supposedly a non-supported method of passing files as arguments
(instead of the normal stdin method) to rpmdeps. Turns out
rpmdeps is even documented to take files as cli args, and that's
how Fedora's %filter_setup macros are calling it...
- Allow files as arguments again, but in a way that doesn't cause
argvFoo() vs popt crash-n-burn.
- debugedit doesn't support STABS but there are some crazy cases
like PPC Linux kernel which contains both STABS and DWARF debuginfo
sections, manually added. A better fix would be erroring out
if we didn't find any usable debuginfo and warning otherwise but
this at least folks get their kernels built.
- Both relate to reading manifests and it doesn't make the damnest
difference what io mode these use as rpmReadPackageManifest()
opens its own stream on the fd with fdopen() which works on
any io type, not just fpio..
- The common pattern here is grabbing current flags to a local
variable, modifying them for an operation and then restoring,
which is fine... but we dont care about the previous flags
when we're restoring them.
- Depgen helpers take nno args, their input comes from stdin. Eliminates
popt vs ARGV_t mismatch which would've caused us to blow up if
it weren't for a memleak on the generated argv.
- Another memleak on the file classifier in case rpmfcClassify()
or rpmfcApply() fails - just free all allocated resources at exit.
- Remove fluff: fgets() is guaranteed to \0-terminate non-NULL returns,
eliminate unused/useless variables
- Fixup indentation where busted
- The previous "silently ignore" policy produces bogus debuginfo
packages on some architectures and fails with other mysterious
errors on others, better just fail hard until (if ever) somebody adds
stabs support.
- rpmfcClassify() or rpmfcApply() failing is pretty fatal to rpmdeps,
exit with error code
- OTOH argvAdd() and argvSort() can't really fail, ignore their return
codes, shutting up another set-but-not-used whine
- It contains piles of buffer overflow etc material and AFAIK this
has been unused for its entire lifespan of > 10 years, fixing
an unused piece of code seems like a waste of time. If somebody
shows interest later on it can be resurrected, but in the meanwhile...
- rpmdeps calls the internal dependency generator as an external
dependency generator (yes its more than a bit wacky), and the
internal generator needs to know the buildroot as path patterns
expect non-buildroot paths for accuracy.
- Technically this changes the rpmcliQuery() and rpmcliVerify() API
in the sense that we no longer honor the qva->qva_flags for the
--nosignature and others, but we assume anybody using these (as if
anybody was using the "cli" API) uses rpmcliInit() which takes
care of these common bits... shrug.
- Ditch ancient and hidden --nopgp --nogpg switches along with the
dishwater which are simply alias to --nosignature.
- Eliminate now unused qva_flags from rpmInstallArguments (along with
a double vsflags goo from rpmgraph)
- Signing is better done in an environment completely separated from
the process of actually building packages. This is how its generally
done anyway by distros, this change just forces the issue.
- While signing on build seems handy and saves some io-churn, this
is very insecure as your precious secret passphrase remains unencrypted
in memory for the entire duration of the build where it's accessible
to whatever happens to be building. This change doesn't
affect fix the issue of unencrypted passphrase residing in memory
and potentially getting swapped out, it only limits the exposure
to the actual signing process which isn't subject to unknown scripts
poking around.
- Minimally preserve rpmbuild's --sign functionality via popt --pipe hack
to call rpm --addsign when build completes
- Elf dependency extraction code code lifted from rpmfcELF() and refactored
to saner pieces. Having it in separate executable also frees librpmbuild
of libelf dependency, clean up the unnecessary linkage etc from
autofoo
- This lets internal dependency generator for elf files be
overridden without losing file coloring (which is required for
correct multilib handling). It also permits non-native elf files
(eg when cross-building) to be handled by providing a custom
elf dependency helper
- On the flip side, this inevitably slows down builds somewhat as
two fork-exec's are needed for every elf file, but unlike invoking
something like the python interpreter, this is a slim helper...
- All dependency extractors of the internal dependency generator are now
external helpers (how twisted is that, huh? :) and thus can be customized
and filtered through %__foo_provides|requires macros
Panu Matilainen