On 24.01.2021 20:38, Jacek Caban wrote:
On 22/01/2021 20:34, Martin Storsjö wrote:
On Fri, 22 Jan 2021, Jacek Caban wrote:
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.
It indeed sounds nice. I experimented a bit a got it working, I will send patches after clean up and some testing. This way we may stop requiring llvm-ar and llvm-ranlib as well.
My first attempt didn't work because llvm-link does not support -def option, which would allow creating a library from both object files and def file in one pass. I got it working with two passes (which is similar to how we handle other platforms anyway): first exec lld-link -implib to generate importlib, then lld-link /lib to create a static library.
I had another look at it and I sent the part that replaces use of llvm-ar and llvm-ranlib with lld-link /lib. However, I couldn't get importlibs using lld-link -implib right. I tried MSVC, suspecting that something is wrong with lld-link, but I found that what I was trying to do is not supported by link.exe. -implib option is really meant for an addition to linker, not for importlib-only execution.
Unless I'm missing something, llvm-dlltool is currently the only supported way to do that using current LLVM. We could look at -def option support in llvm-lib, but a symlink in Ubuntu will be needed for now.
Thanks,
Jacek