On 8/14/24 06:25, Eugene Syromiatnikov wrote:
On Wed, Aug 14, 2024 at 05:14:08AM -0600, Shuah Khan wrote:
On 8/13/24 10:33, Eugene Syromiatnikov wrote:
On Mon, Aug 12, 2024 at 05:03:45PM -0600, Shuah Khan wrote:
On 8/12/24 10:56, Eugene Syromiatnikov wrote:
The relative RPATH ("./") supplied to linker options in CFLAGS is resolved
relative to current working directory and not the executable directory,
which will lead in incorrect resolution when the test executables are run
>from elsewhere. Changing it to $ORIGIN makes it resolve relative
to the directory in which the executables reside, which is supposedly
the desired behaviour. This patch also moves these CFLAGS to lib.mk,
so the RPATH is provided for all selftest binaries, which is arguably
a useful default.
Can you elaborate on the erros you would see if this isn't fixed? I understand
that check-rpaths tool - howebver I would like to know how it manifests and
One would be unable to execute the test binaries that require additional
locally built dynamic libraries outside the directories in which they reside:
[build@builder selftests]$ alsa/mixer-test
alsa/mixer-test: error while loading shared libraries: libatest.so: cannot open shared object file: No such file or directory
how would you reproduce this problem while running selftests?
This usually doesn't come up in a regular selftests usage so far, as they
are usually run via make, and make descends into specific test directories
to execute make the respective make targets there, triggering the execution
of the specific test bineries.
Right. selftests are run usually via make and when they are installed run through
a script which descends into specific test directories where the tests are installed.
Unless we see the problem using kselftest use-case, there is no reason the make changes.
The reason has been outlined in the commit message: relative paths in
RPATH/RUNPATH are incorrect and ought to be fixed.
Sorry I am not going be taking these patches.
I see, by the same token, kernel maintainers reject any patches that fix
compilation/build warnings, I guess.
No - compilation and build warnings are accepted. This doesn't fall into that
case. As you mentioned you can't reproduce this using the kselftest use-cases.
Hence the reason to reject.
thanks,
-- Shuah
[Index of Archives]
[Pulseaudio]
[Linux Audio Users]
[ALSA Devel]
[Fedora Desktop]
[Fedora SELinux]
[Big List of Linux Books]
[Yosemite News]
[KDE Users]
