I cannot say that I understand the purpose behind the match_so_flags
function.  Is it supposed to be an exhaustive check?  Just a quick
check?  Is it always required to find the DSO which would be used
by the current process?  Should there be an overwrite?

In any case, the current way seems to be wholly inadequate.  It
somehow assumes a specific order of the DSO in the list read from
the ld.so cache.  That's fragile at best.

In the case of one of my machines, I run a x86-64 process and try
to find a symbol in libc.  The first DSO returned in the cache
matching "libc.so" is /libx32/libc.so.6 (i.e., the x32 version of
libc).  Using the file works but the DSO is not used.

I assume the idea behind the short form "c" for the module name
is to use the DSO of the same type as the running process.  As is
all platforms not matching the listed 64-bit platforms are blindly
accepted.

I suggest at the very least to check for the case of the non-64-bit
DSO in the cache to check that the running program is also 32-bit.
This patch does this.

In the longer run a more robust check should be implemented which
compares the current process' ELF header with that of the found DSO.
If this is the desired direction let me know and I'll come up with
a patch.