[PATCH] winnt.h: Fix MSVC variants of InterlockedIncrement16 and InterlockedDecrement16.
Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> --- FWIW, depending on distro, building in this mode may be as easy as adding CROSSCC=clang to configure. include/winnt.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
On Fri, 22 Jan 2021, Jacek Caban wrote:
Signed-off-by: Jacek Caban <jacek(a)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. // Martin
On 22.01.2021 15:18, Martin Storsjö wrote:
On Fri, 22 Jan 2021, Jacek Caban wrote:
Signed-off-by: Jacek Caban <jacek(a)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. 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). Thanks, Jacek
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(a)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. // Martin
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. Thanks, Jacek
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
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. // Martin
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. // Martin
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. I'm attaching a minimal test case reproducing it without winebuild. I get: $ make test lld-link -machine:i386 -def:test.def -implib:libtest.a clang -o test.exe -fuse-ld=lld test.c -nodefaultlibs -nostartfiles libtest.a -Wl,-entry:testentry -target i686-windows -Wl,-subsystem:windows winedump -j import test.exe |grep TestFunc 00002030 1 _TestFunc(a)0 Maybe I'm missing something. It might be an intended behaviour, that's why I tried to experiment with link.exe. Thanks, Jacek
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
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(a)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
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
participants (2)
-
Jacek Caban -
Martin Storsjö