- User Since
- Nov 13 2016, 5:55 AM (294 w, 2 d)
Fri, Jun 10
May 30 2022
Confirmed today it solves the problem.
May 18 2022
Thank you! It will surely make building easier.
Mar 2 2022
Rebuilt Rust with this patch applied to host LLVM and it still works after stripping binaries and libraries.
Feb 10 2022
Jan 27 2022
Looking at Rust's fix over https://github.com/rust-lang/rust/commit/4f0ad1c92ca08da6e8dc17838070975762f59714 seems like there is API added in Windows 10 to solve it (I don't know how effective though).
I'm not going to work on this myself but leaving the link in case somebody else wants to give it a try.
Jan 3 2022
Jan 2 2022
There was similar differential recently: https://reviews.llvm.org/D112093
Oct 20 2021
I never had to dig into subsystem versions and what do the mean but looking at subsystem docs 4.0 stands for kernel mode drivers which looks wrong to me. They also specify 5.01 as 32-bit, 5.02 as 64-bit and 6.0 as being either 32-bit or 64-bit.
Oct 2 2021
Agree, we should promote using working and tested configuration.
Even if pthread build works it's probably affected by threading issues when built with GCC.
Aug 4 2021
Aug 2 2021
Aug 1 2021
From a quick look at the options listing, I presume most other cases of S<> and J<…=> should be changed into Eq<> too.
Jul 23 2021
Building only X86 target did the trick and it looks good:
$ ls bin/ | rg libLLVM.*dll libLLVM-13git.dll
Jul 21 2021
I had no internet during the weekend (massive storms over here) but so I returned to it yesterday.
I'm unable to build clean main branch at the moment:
` [2972/3064] Linking CXX shared library bin\libLLVM.dll FAILED: bin/libLLVM.dll lib/libLLVM.dll.a cmd.exe /C "cd . && D:\msys64\clang64\bin\c++.exe -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -ffunction-sections -fdata-sections -O3 -DNDEBUG -Wl,--gc-sections -shared -o bin\libLLVM.dll -Wl,--out-implib,lib\libLLVM.dll.a -Wl,--major-image-version,0,--minor-image-version,0 @CMakeFiles\LLVM.rsp && cd ." lld-link: error: too many exported symbols (max 65535) `
It's simple change though, should I update diff without testing?
LGTM sorry for the delay.
Jul 16 2021
Jul 4 2021
Jul 3 2021
Jun 26 2021
LGTM once D104530 is merged.
Jun 14 2021
Feels a bit like approving myself (which is only partially true) but I don't see any issues with the patch itself.
May 28 2021
Ah, so that explains why everyone sends LGTM text.
I'll try to remember it next time.
May 27 2021
May 22 2021
Wow, I haven't expected that.
May 21 2021
Feels like a heavy hammer to me but guess there is no better option.
FWIW at MSYS2 we build LLVM with both GNU and LLVM toolchains for different "subsystems".
GNU's LLD was deadlocking a lot so we have patched it to use TerminateProcess and it worked around all deadlocks except when running tests (the patch probably needs more work on it), we don't apply it for LLVM's LLD because I thought it's a bit overkill.
May 18 2021
Funny but I've hit this deadlock (LLVM_LINK_LLVM_DYLIB, LLD_DEFAULT_LD_LLD_IS_MINGW and shared libc++) last week in single LLD unit test. It never reproduced despite dozen of LLD testsuite runs.
May 14 2021
When building with ninja, the output is buffered so the warnings appear directly after the specific build target that cause them.
But I don't know if ld.bfd actually implements the -z options for PE targets?
Fix typo and the test
I don't know when they exactly appear but look at my building log: https://reviews.llvm.org/P8263
The build was done with 16 threads so it's hard to tell which objects made it appear.
May 13 2021
Sorry I thought it's simple enough on it's own.
May 11 2021
Apr 30 2021
The change itself looks correct but cannot speak for the test.
Apr 29 2021
If compiling with GCC or linking with ld.bfd, these options have little
Apr 6 2021
I saw https://github.com/msys2/msys2-runtime/issues/36 but I have never worked with MSYS2 runtime internals so you probably know more than I do at this point.
https://github.com/dscho who maintains Git for Windows might have some insights.
Mar 5 2021
It's clear overlook from D79995, that part is perfectly reasonable to me.
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
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
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".)