Sorry for the delay.
LGTM from MinGW point of view.

Opened https://reviews.llvm.org/D89225

Or maybe even make it into a cmake option?

Older versions of lld didn't error out if exceeding the limit, this is fixed in D86701, unfortunately after the 11 branch.

With -DLLVM_ENABLE_ASSERTIONS=ON -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_RANLIB_COMPILER=llvm-ranlib -DCMAKE_AR_COMPILER=llvm-ar -DCMAKE_LINKER=ld.lld -DLLVM_ENABLE_LLD=ON libclang-cpp.dll has 65535 exports, seems it got truncated?

Reproduced by adding -DLLVM_ENABLE_ASSERTIONS=ON.

How many exports does your DLL end up with - is it close to the 64k limit, or far from it? Is there maybe some other library that is linked in, that increases the number of exported symbols (=all), or does this DLL only export explicitly intended symbols with dllexport?

@ASDenysPetrov what CMake options do you use?
I'm unable to reproduce this error with Clang+LLD and GCC+Binutils from MSYS2.

I wonder if it'd be possible to add some custom substitution in the lit config, to have it replace ld.lld with ld.lld -m <some-elf> in this case...

With BFD (tested version 2.35) the latter specified option takes precedence:

Nit: according to https://docs.microsoft.com/en-us/cpp/build/reference/subsystem-specify-subsystem?view=vs-2019 the minimal and the default subsystem for ARM should be 6.02.

@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.