building: validate binaries returned by analysis of ctypes calls

[rokm]

Validate binaries returned by analysis of ctypes calls in collected modules; the analysis might return files that are in PATH but are not binaries, which then cause errors during binary dependency analysis. An example of such problematic case is the gmsh package on Windows, where ctypes.util.find_library('gmsh') ends up resolving the python script called gmsh in the environment's Scripts directory (see #7982).

[rokm]

This is the last-line-of-defense kind of thing. In the future, we might want to also remove the Scripts directory from library search paths (both in ctypes-based analysis and the regular binary dependency analysis).

[bwoodsend]

Doesn't that mean that there is still a gmsh.dll which we are not collecting but should? Shouldn't we be swapping out the ctypes.util.find_library() for an implementation which does the filtering and keeps searching if an invalid file is picked up?

[rokm]

Doesn't that mean that there is still a gmsh.dll which we are not collecting but should? Shouldn't we be swapping out the ctypes.util.find_library() for an implementation which does the filtering and keeps searching if an invalid file is picked up?

Indeed. But it is actually called gmsh-4.11.dll, and lives in the environment's Lib, which is not in PATH, and thus cannot be discovered by ctypes.util.find_library().

Which is why the gmsh search code looks like this (the released version is 4.11, the git version is 4.12):
https://gitlab.onelab.info/gmsh/gmsh/-/blob/master/api/gmsh.py?ref_type=heads#L41-86

[...]
moduledir = os.path.dirname(os.path.realpath(__file__))
parentdir1 = os.path.dirname(moduledir)
parentdir2 = os.path.dirname(parentdir1)

if platform.system() == "Windows":
    libname = "gmsh-4.12.dll"
elif platform.system() == "Darwin":
    libname = "libgmsh.4.12.dylib"
else:
    libname = "libgmsh.so.4.12"

# Searching lib in various subfolders
libpath = None
possible_libpaths = [os.path.join(moduledir, libname),
                     os.path.join(moduledir, "lib", libname),
                     os.path.join(moduledir, "Lib", libname),
                     # first parent dir
                     os.path.join(parentdir1, libname),
                     os.path.join(parentdir1, "lib", libname),
                     os.path.join(parentdir1, "Lib", libname),
                     # second parent dir
                     os.path.join(parentdir2, libname),
                     os.path.join(parentdir2, "lib", libname),
                     os.path.join(parentdir2, "Lib", libname)
                     ]

for libpath_to_look in possible_libpaths:
    if os.path.exists(libpath_to_look):
        libpath = libpath_to_look
        break

# if we couldn't find it, use ctype's find_library utility...
if not libpath:
    if platform.system() == "Windows":
        libpath = find_library("gmsh-4.11")
        if not libpath:
            libpath = find_library("gmsh")
    else:
        libpath = find_library("gmsh")

# ... and print a warning if everything failed
if (not libpath) or (not os.path.exists(libpath)):
    print("Warning: could not find Gmsh shared library " + libname)
    print("Searched at these locations: " + str(possible_libpaths))

lib = CDLL(libpath)
[...]

So the library is not actually discoverable by ctypes, at least not on Windows. But they still have a codepath for it, and that codepath triggers resolution of gmsh script in Script directory.

[rokm]

So for actually collecting the lib, the user would have to use --add-binary or write a hook that queries gmsh.libpath.