symbolextractor: detect DLL name with llvm-nm/nm

[robUx4]

lib.exe, llvm-lib and dlltool may not be available (as in llvm-mingw), the LLVM nm tool may be available. It lists the DLL for each export symbol, so we can get the DLL name from there.

[mstorsjo]

dlltool may not be available (as in llvm-mingw)

Llvm-mingw does have something like dlltool, but in unix toolchain setups, the tool is only available in the form <triple>-dlltool - just in the same way as for GNU binutils when cross compiling.

(However, llvm-dlltool doesn't support the -I flag that meson tries to use here, yet. We can try to look into implementing the option in the future though.)

Secondly; using either lib.exe, llvm-lib or llvm-nm to list the archive member names won't do the right thing for the "long import library" format produced by GNU tools. With such import libraries, the archive member names are things like d01234.o, not mylib.dll. But if we try using dlltool before this, it's probably somewhat safe. (It may even be safer to try dlltool before lib and llvm-lib.)

But it would be very valuable if Meson would try to look for the triple-prefixed version of dlltool, too. (But would that require heuristics for guessing the tool name, unless we have dlltool in cross files?)

[robUx4]

But it would be very valuable if Meson would try to look for the triple-prefixed version of dlltool, too. (But would that require heuristics for guessing the tool name, unless we have dlltool in cross files?)

This script is called from ninja. Maybe passing the crossfile in addition (or instead) to the --cross-host option could help set whatever the toolchain uses as the dlltool (or nm) variant.

[eli-schwartz]

        # In case of cross builds just always relink. In theory we could
        # determine the correct toolset, but we would need to use the correct
        # `nm`, `readelf`, etc, from the cross info which requires refactoring.

Refactoring to plumb this information through seems entirely acceptable...