User Details
- User Since
- Nov 13 2016, 5:55 AM (218 w, 2 d)
Oct 25 2020
Sorry for the delay.
LGTM from MinGW point of view.
Oct 12 2020
Oct 10 2020
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.
Oct 9 2020
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.
Oct 7 2020
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...
Oct 5 2020
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.
Sep 26 2020
@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.
Sep 22 2020
Sep 21 2020
LGTM
Confirmed that GCC 9 still adds .exe.
Sep 14 2020
Sounds great, could you commit it? I don't have the permission.
Sep 13 2020
Cygwin seems to be the only Windows target that adds version to the library names.
Sep 12 2020
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
Sep 11 2020
-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.
Sep 10 2020
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.
Sep 9 2020
Aug 27 2020
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.
Aug 26 2020
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.
Aug 25 2020
@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.
Aug 24 2020
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.
Aug 23 2020
I'll update it soon.
Indeed, I apologize for bothering you. Should I move the discussion to one of patches created by @haampie?
Aug 22 2020
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
Aug 4 2020
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.
Jun 23 2020
Jun 3 2020
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.
Jun 1 2020
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?
May 28 2020
No worries.
Mateusz Mikuła <mati865@gmail.com>
Added test.
May 26 2020
May 24 2020
May 23 2020
May 22 2020
May 15 2020
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.