Re: clang: selftests/mm gup_longterm error while loading shared libraries liburing.so.2 cannot open shared object file No such file or directory

[David Hildenbrand]

On 16.06.25 21:14, Christian Heusel wrote:
> On 25/06/16 11:02PM, Naresh Kamboju wrote:
> > The following test regressions noticed while running selftests/mm gup_longterm
> > test cases on Dragonboard-845c, Dragonboard-410c, rock-pi-4, qemu-arm64 and
> > qemu-x86_64 this build have required selftest/mm/configs included and toolchain
> > is clang nightly.
> >
> > Regressions found on Dragonboard-845c, Dragonboard-410c, rock-pi-4,
> > qemu-arm64 and qemu-x86_64
> >    -  selftests mm gup_longterm fails
> >
> > Regression Analysis:
> >   - New regression? Yes
> >   - Reproducibility? Yes
> >
> > Test regression: selftests mm gup_longterm error while loading shared
> > libraries liburing.so.2 cannot open shared object file No such file or
> > directory
>> Test regression: selftests mm cow error while loading shared 
libraries>> liburing.so.2 cannot open shared object file No such file or 
directory
> These do not really look like kernel regressions, rather like a bug in
> the userspace testing tool 🤔 Could it be that the tests were not
> rebuilt for the new liburing or that the dependency is not installed in
> the test environment?

It looks like the tests were build with liburing around, and then ran 
without liburing around.

Note that the file for example has:

#ifdef LOCAL_CONFIG_HAVE_LIBURING
#include <liburing.h>
#endif /* LOCAL_CONFIG_HAVE_LIBURING */

You should be running into similar issues with cow.c, which uses the 
exact same approach for detecting+linking liburing.

So seems like something is off in your testing environment?

--
Cheers,

David / dhildenb