On Fri, 7 May 2021, Jacek Caban wrote:
On 1/22/21 8:34 PM, Martin Storsjö wrote:
On Fri, 22 Jan 2021, Jacek Caban wrote:
I think, for some reason, they generally package all tools with a version number suffix (so they don't clash if you have multiple versions in parallel) and then have a userfriendly versionless symlink pointing at the latest installed one, or something like that. But they don't seem to add such symlinks for tools that aren't commonly used (e.g. they have a symlink for llvm-objdump, but not for llvm-readobj).
If there is reason for llvm-dlltool to be problematic, we may try to use llvm-lib (or maybe even let lld-link do that for us).
Not sure if there's a reason for it to be problematic, other than just not a very universally acknowledged tool in itself. (It only implements essentially 1 operation out of the ones that GNU dlltool support as well, generating import libs from def files, needed by the mingw-w64-crt build.)
Reducing the tool interface down from 3 tools to 2 sounds pretty nice though, unless it's too much of a mess.
I revisited that after I found clang -print-prog-name and it seems to be exactly what we need. I sent a patch that uses it to find LLVM tools. With that, winebuild only needs to be able to find clang and leaves the rest for clang.
Oh, nice! I didn't know about -print-prog-name, but that does indeed seem handy!
// Martin