FS#64464 - [lld] usr/include/lld/* are not useful

Attached to Project: Arch Linux
Opened by Ray Song (MaskRay) - Monday, 11 November 2019, 21:30 GMT
Last edited by Evangelos Foutras (foutrelis) - Friday, 24 April 2020, 00:43 GMT
Task Type Feature Request
Category Packages: Extra
Status Closed
Assigned To Evangelos Foutras (foutrelis)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

ldc (https://github.com/ldc-developers/ldc/) is a project that can optionally link against lld (via -DLDC_WITH_LLD=On). extra/lld is not suitable to build ldc.

```sh
% cmake -H. -BArch -G Ninja -DCMAKE_BUILD_TYPE=Debug -DD_COMPILER=$HOME/dlang/dmd-2.089.0/linux/bin64/dmd -DCMAKE_CXX_STANDARD=14 -DLDC_WITH_LLD=On
% ninja -C Arch
...
: CommandLine Error: Option 'mc-relax-all' registered more than once!
% Arch/bin/ldc2
: CommandLine Error: Option 'mc-relax-all' registered more than once!
LLVM ERROR: inconsistency in registered CommandLine options
```

/usr/lib/lldCommon.so.9 has a static constructor `RelaxAll` (stripped, so no symbol) that registers the command line option `mc-relax-all`. The static constructor also occurs in the executable ldc2 (via driver/cl_options-llvm.cpp.o) => conflict. So extra/lld is not suitable for downstream projects. We can delete header files to make it clear.
This task depends upon

Closed by  Evangelos Foutras (foutrelis)
Friday, 24 April 2020, 00:43 GMT
Reason for closing:  Fixed
Additional comments about closing:  lld 10.0.0-2
Comment by Eli Schwartz (eschwartz) - Monday, 11 November 2019, 21:38 GMT
The 'zig' package somehow manages to link to the lld shared libraries, so it plainly can work. Since the static constructor comes from thirdparty code, it seems plainly evident that the thirdparty code is buggy for attempting to overwrite someone else's static constructor, and projects which do not do this, will be fine.

Rather than deleting the 'zig' package from archlinux, maybe you could investigate with the ldc developers, why their project does not properly support lld?
Comment by Ray Song (MaskRay) - Sunday, 01 December 2019, 05:39 GMT
extra/zig can depend on extra/lld because zig does not include llvm/CodeGen/CommandFlags.inc and call InitTargetOptionsFromCodeGenFlags(). zig has not implemented this feature https://github.com/ziglang/zig/issues/2883
liblldCommon.so calls InitTargetOptionsFromCodeGenFlags() for its LTO.

So there is no fundamental issue that prevents a downstream library from using lld libraries but we need to fix the llvm/CodeGen/CommandFlags.inc global constructor problems in llvm (it will be very difficult, though).

Feel free to close it because extra/zig currently supports this scenario. For other projects that use llvm, there is a great chance that they will use InitTargetOptionsFromCodeGenFlags(). Hopefully they can still find the post with the error message.
Comment by Evangelos Foutras (foutrelis) - Sunday, 12 April 2020, 05:05 GMT
I've been notified that the new version of zig is hitting this with LLVM 10.

Looking at ldc's driver/cl_options-llvm.cpp, there seems to be a workaround which avoids linking in lld/Common/TargetOptionsCommandFlags.o.

Perhaps if our lld package shipped static libraries, ldc would work and zig could implement a similar workaround? :)
Comment by Evangelos Foutras (foutrelis) - Sunday, 12 April 2020, 16:02 GMT
Alright, shipping static lld libraries seems to do the trick! I tested llvm+lld {9,10} and ldc 1.20.1 happily compiled against both.

Leaving this task open until lld 10 gets into our stable repos (currently in staging until the llvm 10 rebuilds are done).

Loading...