My workaround wasn’t bad, I’ve found that I just missed one path.
So the replacement now looks like:
sed -i -e 's?%%LDPATH%%?/snap/$SNAPCRAFT_PROJECT_NAME/current/lib:&?' bin/ldpathwrapper;
sed -i -e 's?%%LDPATH%%?/snap/$SNAPCRAFT_PROJECT_NAME/current/usr/lib:&?' bin/ldpathwrapper;
sed -i -e 's?%%LDPATH%%?/snap/$SNAPCRAFT_PROJECT_NAME/current/lib/$SNAPCRAFT_ARCH_TRIPLET:&?' bin/ldpathwrapper;
sed -i -e 's?%%LDPATH%%?/snap/$SNAPCRAFT_PROJECT_NAME/current/usr/lib/$SNAPCRAFT_ARCH_TRIPLET:&?' bin/ldpathwrapper;
sed -i -e 's?%%LDPATH%%?\$LD_LIBRARY_PATH?' bin/ldpathwrapper;
With that I got all the libvirt helpers, dnsmasq and virsh (was only effected if called from other contexts) working.
The usage of the single helper is good as well to avoid proliferation of such wrapper-files.
So -> immediate issue solved \o/
But long term I’d still be interested if there could be a snap/snapcraft provided generic fix to cover those indirect-calls-withotu-env to work.
Maybe a patched version of ld.so that would load LD_LIBRARY_PATH from a place that snapd can keep constant for the snap?
I’ve inserted myself into this Fridays snap-clinic call (mostly before I completed my workaround) there we can talk about potential long term fixes.