On a Wednesday in 2025, Michal Privoznik via Devel wrote:
From: Michal Privoznik <mpriv...@redhat.com>

MacOS has its own dynamic linker (dyld) which is different to
Linux/BSD one. But with a little help (by setting
"DYLD_FORCE_FLAT_NAMESPACE" env var) it would behave similarly to
Linux/BSD ones. In particular, if a library is preloaded via
"DYLD_INSERT_LIBRARIES" on MacOS or "LD_PRELOAD" on Linux/BSD,
then dlsym(RTLD_NEXT, ...) considers ALL preloaded libraries. For
instance, the virFileCanonicalizePath() is reimplemented in
virpcimock and qemuxml2argvmock. Each one of these
reimplementations uses dlsym(RTLD_NEXT, ...) to look up and call
virFileCanonicalizePath() from next library in the queue and
possibly even the actual implementation from libvirt.so.

This chaining of mocks allows us to have mock libraries that
create stable, reproducible environment for tests.

Now, because of unknown reason Apple decided to remove the flat
namespace feature [1] (I recommend to just clone the repo and
view the commit via 'git show' as github's web interface hides
interesting bits away). They did so in 2022. And it wasn't until
my commit of v11.6.0-19-g12c35ab161 that we've noticed this,
because until that commit no two mock reimplemented the same
function. Well, now they do and with flat namespaces gone the
dlsym(RLTD_NEXT, ...) returns an address from libvirt.so instead
of from next mock on the list.

Since reimplementation of virFileCanonicalizePath() in
qemuxml2argvmock.c is only to cover a case on some Linux systems
and virpcimock.c creates full sysfs imitation of PCI devices, the
latter is more important than the former.

Therefore, switch order of those mocks.

On Linux/BSD this has virtually no effect, but on MacOS it fixes
the qemuxmlconftest failure.

1: 
https://github.com/apple-oss-distributions/dyld/commit/9a9e3e4cfa7de205d61f4114c9b564e4bab7ef7f

+63898 -114767 *facepalm*

Signed-off-by: Michal Privoznik <mpriv...@redhat.com>
---
tests/qemuxmlconftest.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)


Reviewed-by: Ján Tomko <jto...@redhat.com>

Jano

Attachment: signature.asc
Description: PGP signature

Reply via email to