Hi,
On Tue, 16 Feb 2021, Jacek Caban wrote:
On 15.02.2021 12:58, Martin Storsjö wrote:
On Wed, 10 Feb 2021, Martin Storsjö wrote:
On Wed, 10 Feb 2021, Jacek Caban wrote:
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.
It does seem to work for me, e.g. like this:
link.exe -lib -machine:arm64 -def:test.def -out:test.lib
However lld-link doesn't implement that combination, so you're right that llvm-dlltool is the one we have to use for now. I guess I should look into implementing that option combination at some point though.
Actually, lld-link has implemented a very similar variant:
lld-link -machine:arm64 -def:test.def -implib:test.lib
Which does the equivalent of
link.exe -lib -machine:arm64 -def:test.def -out:test.lib
This hasn't been implemented in llvm-lib though (which is what you get when calling lld-link /lib); it'd require moving a couple functions out from lld into the lower level libraries/interfaces that are shared with llvm-lib.
If you're ok with deviating from the strict MSVC interfaces, then just "lld-link -machine: -def: -implib:" does that though.
I tried that and I couldn't get it to work. That's what this patch does:
https://source.winehq.org/patches/data/198665
x86 build with that patch has broken imports because it includes stdcall decorations in import table. I couldn't make it stop doing that. With additional '=undecoredsymbol' in .def files I could strip leading underscore, but import entries still contained '@argsize' part.
Ah, right, hmm.
I think that link.exe style linkers requires you to actually do linking from object files, to be able to deduce those aspects (that symbols have decoration but dll export names don't), and it can't describe those nuances properly just by the def file. Creating the def files with *dlltool fixes that as long as the -k option is used though.
So yeah, for i386, a dlltool that supports the -k option is pretty much required, I think.
// Martin