Log: tests: show the corresponding library name in case of error upon opening libaio.so

[gao-yan]

No description provided.

[wenningerk]

Ooops obviously a leftover.
Anyway did you check what dlerror() would give us here?
Man page doesn't tell if it is a simple error-code translation or if we get an actual reference to the library it failed on.
Maybe more descriptive and we might not have to keep that in sync.

[gao-yan]

Well, this is only about the inconsistency...

Actually the main issue for me now is, at least in the seemingly convention of SUSE Linux, library files always have a major version as the suffix, for instance libaio.so.1 is a symbolic link to libaio.so.1.0.1 while there's not a libaio.so.

So sbd test fails to find the library file at all for me now.

[wenningerk]

That is the reason why it was initially libaio.so.1 - as left over in the logs.

Don't remember the reason for the switch. I remember there was something in tumbleweed iirc but I'm not sure that this was the reason to switch. Let me consult the git-logs - maybe that rings a bell ...

On the other hand there is already the mystery why loading this library is needed here in the first place (and RTLD_NEXT not working iirc). Not sure if I ever understood that really - well at least I don't remember now.

Unfortunately I don't know an easy way to do the libaio-wrapping just conditionally when it is requested to translate the aio interface to read/write for cases where the test-environment doesn't allow the use of the aio-syscalls. Maybe reinvestigating this could lead to a solution that in most cases doesn't have to open an explicit library.

We might as well get the library-name in configure so that it would adapt automatically to the distribution.

A bit unsatisfactory but another viable solution would be to make libaio-wrapping a compile-time-switch.

[gao-yan]

Makes sense.

BTW, need to look more into it, but probably depending on the versions of the toolchain (glibc/bintuils...) , it seems to work in certain cases without requiring the specific file libaio.so to be existing ...

[wenningerk]

Maybe some kind of automatism in the dynamic library loader ...
If you have explicit cases that work and some that don't it would be helpful to have a hint for getting that covered in CI if somehow possible.

[gao-yan]

Alright, I see. It works only if libaio-devel is as well installed, which provides the symbolic link libaio.so.

[wenningerk]

Helpful finding! (That brings back my memory that I had switched to libaio.so for that version of tumbleweed that came with 2 versions of libaio.) Possibility would be to include the devel requirement into the test-subpackage. But that would probably not be too clean. Best might be to have configure find what libaio.so is linking to and bake that into the test-subpackage.