Re: [PATCH v2] selftests: fix relative rpath usage

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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.





[Index of Archives]     [Pulseaudio]     [Linux Audio Users]     [ALSA Devel]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux