| Issue |
142798
|
| Summary |
LLD: Support --unresolved-symbols=@path/to/file option for lld
|
| Labels |
lld
|
| Assignees |
|
| Reporter |
Nechda
|
### lt;dr
Let's add another use case for the `--unresolved-symbols` linker flag. This flag will read a list of symbols that may be undefined at linking time. The usage would be `--unresolved-symbols=@/path/to/file`.
### Context:
The common problem when linking statically with CUDA-like libraries, such as cuDNN and TensorRT, is related to undefined symbols that should be defined in the libc++ standard library (libcstd++.so). This can cause issues if the symbols are not present on the development host, but are present in the production environment.
Previously, our approach was straightforward: we simply created a library with empty stubs. The static linking worked fine, and the stubs were not used in the development environment. However, the latest update of TensorRT requires a more complex function that cannot be replaced with a simple stub - the inner implementation of std::thread.
A naive approach to solving this problem would be to simply update libcstd++.so on all development hosts. However, this approach is difficult to complete in a short period of time and is also not scalable for the long term.
### Proposal
Let's extend the behavior of the `--unresolved-symbols` flag to include one more use case: `--unresolved-symbols=@/path/to/file`. This will read a list of symbols from the specified file and ignore errors related to any unresolved symbols mentioned in the list.
The default usage of the `--unresolved-symbols=ignore-all` flag is not appropriate in this case, as it may hide the actual problem with unresolved symbols.
![]()
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
