IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Most of the binaries on mipsel do not contain the stack section,
so this check is not relevant for that architecture. Morover,
it fails, since it can't find the stack section, which is
(rightfully) not present.
eu-elflint does not understand mipsel binaries currently,
so here we disable that check, too.
Previously (according to the exit statuses):
0. if something strange was found in $rpath, an error was reported;
1. if nothing strange was found, no error was reported;
2. if grep failed, it looked like the previous case and no error was
reported (as if $rpath was valid).
Now, the pipe (and the whole script) would abort on grep's failure.
Now, if something fails, the pipe (and the function, and the whole
script) will fail.
If the exit codes are normal, they are handled according to our logic.
Previously, a failure (which is an exceptional rare case) would lead to:
1. skipping the further exe_stack check and error_strict STACK "$f" 'STACK entry not found'
2. silently skipping the exe_stack check (which was impossible anyway because of the failure)
The pipe (and the function, and the whole script) would fail when the
resulting constructed rpath was empty. But usually at least
$RPM_VERIFY_ELF_LDD_RPATH is not empty, so the bad behavior has not
been observed.
However, when verify-elf is used standalone, $RPM_VERIFY_ELF_LDD_RPATH
is empty indeed, and this improvement becomes important.
Before this improvement:
$ RPM_BUILD_ROOT=/home /usr/lib/rpm/verify-elf /bin/pwd; echo $?
1
After this improvement:
$ VERIFY_ELF_UNRESOLVED=strict RPM_BUILD_ROOT=/home /usr/lib/rpm/verify-elf /bin/pwd; echo $?
0
$ VERIFY_ELF_UNRESOLVED=strict RPM_BUILD_ROOT=/home /usr/lib/rpm/verify-elf /usr/lib64/python3/site-packages/_cffi_backend.cpython-35m.so; echo $?
verify-elf: ERROR: /usr/lib64/python3/site-packages/_cffi_backend.cpython-35m.so: undefined symbol: PyExc_SystemError
....
1
When the given ELF file doesn't specify PT_INTERP, e.g. if it's a shared
library, we have to guess it. We used to try the program interpreter
of dump_ld_config, but it doesn't work well enough in multilib
environments, so extend the guess by trying interpreters listed
in RTLDLIST from /usr/bin/ldd script.
Add a brp interface for checking contents of files in buildroot.
The initial revision of brp-check_contents scripts checks
for suspicious path names like /var/lib/run, complementing
the change introduced in sisyphus_check-0.8.43-alt1.
When scanning files for deps, debuginfo, fixup, and verify_elf,
ignore files with type that matches "ELF * shared object, no machine, *"
pattern.
These are ELF files generated by GNU Guile, ignore them for now.
In verify_unresolved(), do not preload requested objects to $elf_ldd
directly because the latter is not an ELF interpreter but a shell
script. Instead, pass the list of objects that have to be preloaded
to $elf_ldd script which in turn assigns it to LD_PRELOAD variable
in the ELF interpreter invocation.
Previously, verify_lfs checked if object has valid interpreter, but it
doesn't make sense in case of shared objects. verify_lfs check is valid
for all ELFs linked with libraries supporting both LFS and non-LFS API
(libc.so and libz.so in our case).
From ld.so's documentation about the search order:
Using the directories specified in the DT_RPATH dynamic section
attribute of the binary if present and DT_RUNPATH attribute does not
exist. Use of DT_RPATH is deprecated.