On 1/22/21 8:34 PM, Martin Storsjö wrote:
On Fri, 22 Jan 2021, Jacek Caban wrote:
On 22.01.2021 15:18, Martin Storsjö wrote:
On Fri, 22 Jan 2021, Jacek Caban wrote:
Signed-off-by: Jacek Caban jacek@codeweavers.com
FWIW, depending on distro, building in this mode may be as easy as adding CROSSCC=clang to configure.
Regarding this, iirc it requires clang, lld-link and llvm-dlltool. The former two are easily available, but at least in ubuntu packages, the latter is only available in version-suffixed form as llvm-dlltool-7 or so.(I guess I should try to figure out whom to poke to get it available unsuffixed.) But maybe it's more available in other distros.
Yeah, it sounds like an Ubuntu bug, it's probably just missing a symlink.
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.
Jacek