@hans sorry for not spotting it earlier but is it possible to still backport it to LLVM 11?
It's totally OK if it's too late. I can easily keep it as a patch in MSYS2 repository.

LGTM
Confirmed that GCC 9 still adds .exe.

Sounds great, could you commit it? I don't have the permission.

Cygwin seems to be the only Windows target that adds version to the library names.

Thanks.

Sorry, pasted wrong command. I was curious if import library has it (since static one did not) but in the end neither import nor static library shows any export.

what code appends a version number in dynamic libs when built for other platforms, but decides not to, when targeting windows in general, or mingw specifically?

bin/llvm-readobj --coff-directives lib/liblibclang.dll.a | grep -i export shows nothing.

Could you fix the title+description?

We had this patch at MSYS2 for years and I'm not aware of any issues with the static library.
I think the library looks fine:

$ nm lib/liblibclang.a | grep __imp_
                 U __imp___acrt_iob_func
                 U __imp___acrt_iob_func
                 U __imp_GetModuleFileNameA
                 U __imp_VirtualQuery
                 U __imp___acrt_iob_func
                 U __imp___acrt_iob_func
                 U __imp___acrt_iob_func

I don't use MSVC but apparently there is no libLLVM there: https://github.com/llvm/llvm-project/blob/9c651c231f3144f53e13cd0a1747589e1b2edccd/llvm/tools/llvm-shlib/CMakeLists.txt#L15

-DLLVM_ENABLE_PROJECTS="clang;lldb" -DLLVM_BUILD_LLVM_DYLIB=1 with only this patch applied (< is before, > is after):

$ diff <(cd ../build && find ./ | sort) <(cd ../build2/ && find ./ | sort)
38a39,41
> ./bin/libLLVM.dll
> ./bin/libLTO.dll
> ./bin/libRemarks.dll
51d53
< ./bin/LLVM.dll
119d120
< ./bin/LTO.dll
123d123
< ./bin/Remarks.dll
1460a1461
> ./lib/libclang.dll.a
1500,1501c1501
< ./lib/liblibclang.dll.a
< ./lib/libliblldb.dll.a
---
> ./lib/liblldb.dll.a

I haven't tried BUILD_SHARED_LIBS=TRUE TBH.

Also adjusted llvm-config.

Updated the diff.

How widespread are these build systems that parse help output? (Given that it took until now to discover them, I'd venture "not very".)

Thanks for the explanation.

FYI this doesn't fully fix MinGW issue:

$ cat tools/llvm-config/BuildVariables.inc | grep LLVM_SYSTEM_LIBS
#define LLVM_SYSTEM_LIBS "-lpsapi -lshell32 -lole32 -luuid -ladvapi32 -lz.dll"

It's because libraries are found by their import library which is libz.dll.a in this case.
libz.dll.a matches if in line 213 and gets stripped to z.dll which doesn't match shared library regex lib.*\.dll.

This really should have been the default for years but it didn't work properly with ld.bfd: https://github.com/msys2/MINGW-packages/issues/6674
Since it already work good with COFF backend when targeting MSVC I'm strongly in favour of enabling it for MinGW as well.

I don't have write permission, could somebody commit it for me?
Thanks in advance.

@mstorsjo @hans I apologize but we will have to backport https://reviews.llvm.org/D86552 (should affect only MinGW so it's rather low risk) or revert this cherry-pick on LLVM 11 branch.

Indeed, hardcoding z3 was stupid oversight from my side.

Could you commit it for me please? I don't have write permission to the repo.

Could you commit it for me please? I don't have write permission to the repo.

Updated the diff.

Updated diff to remove _MSC_VER change.

Thank you, now it works as expected:

$ cat tools/llvm-config/BuildVariables.inc | grep LLVM_SYSTEM_LIBS
#define LLVM_SYSTEM_LIBS "-lpsapi -lshell32 -lole32 -luuid -ladvapi32 -lz"

Only if weak works properly with GCC as well.

I'll update it soon.

@phosek

Looks like that's an issue introduced by D86134 or D86245.

Indeed, I apologize for bothering you. Should I move the discussion to one of patches created by @haampie?

I was using Clang 10 during tests. I can repeat it with Clang 11 tomorrow/next week if you want.

Regarding __attribute__((weak)) it should work fine in Clang 11 now

@phosek in MSYS2 (targeting x86_64-w64-windows-gnu) Zlib works properly for LLVM 10 but with master I'm now seeing:

-- Constructing LLVMBuild project information
-- DEBUG zlib_library=D:/msys64/mingw64/lib/libz.dll.a
CMake Error at lib/Support/CMakeLists.txt:9 (string):
  string sub-command REGEX, mode REPLACE: regex "^(lib|)" matched an empty
  string.
Call Stack (most recent call first):
  lib/Support/CMakeLists.txt:226 (get_system_libname)

-- DEBUG zlib_library=D:/msys64/mingw64/lib/libz.dll.a was printed by my change to help debugging it.
FYI zlib_library is set here: https://github.com/llvm/llvm-project/blob/8e06bf6b3a2e8d25e56cd52dca0cf3ff1b37b5d1/llvm/lib/Support/CMakeLists.txt#L218

Thank you!

At MSYS2 we are using older revision of this patch: https://github.com/msys2/MINGW-packages/commit/e071f276d31a8d214c2f30530eb9ac3ed44fffc7#diff-7f8e056c3dca04423132b5e4e1d36813

Little background:
Recent CMake versions changed behaviour on MinGW and treat .a as static libs only. Currently CMake creates omp.a as the import library and new CMake doesn't like that.

I don't have strong opinion here as I don't know this topic well (things just worked so far).
That said if Clang stops working as a drop-in replacement for GCC with commonly used build systems, MSYS2 will have to carry one more patch to bring back old behaviour.

Thanks, sounds good.

I don't know why AddLibGCC has to be called twice but that doesn't really matter for this diff.

Wouldn't it better fit in AddLibGCC?

No worries.
Mateusz Mikuła <mati865@gmail.com>

Added test.

@mstorsjo @rnk will be away since June

With _GNU_SOURCE removed I was able to successfully build everything without this diff.
I cannot test it today but I believe this updated diff would have fixed the error.

Indeed, I'll see if I can build all LLVM related packages without _GNU_SOURCE. Otherwise I'll guard it with #ifndef _GNU_SOURCE instead.

Perhaps you are building with Clang?
I don't remember the message but GCC emits error about incompatible definition and declaration of vasprintf. I can build it without the patch and paste the error if you want.

Applied review comment and formatted.

Confirming that this patch fixes linking MinGW Rust with LLD.

MSYS2 provides LLVM built with LLVM_BUILD_LLVM_DYLIB=TRUE and hits the same issue. So far it was using this hack: https://github.com/msys2/MINGW-packages/blob/f31bc199ade4d1025cda9bb5aed4427f80d3c584/mingw-w64-clang/0012-fix-testplugin-linking.patch
Applying set(LLVM_LINK_COMPONENTS Core) from this diff also fixes the build.

Can somebody land it before LLVM 8 is branched? Patch author does not have commit access.

@jlpeyton OP doesn't have commit access.