[PATCH] D115500: [llvm] [Debuginfod] Disable CURL by default.

Noah Shutty via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Dec 10 16:23:27 PST 2021


noajshu added a comment.

In D115500#3186076 <https://reviews.llvm.org/D115500#3186076>, @tstellar wrote:

> Thanks for doing this patch.  There was some additional feedback from users that this might not be sufficient: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5732
>
> Would it be better to just not include this library in libLLVM.so ?

Thanks very much for sharing this link!
I like your idea to not include Debuginfod in libLLVM.so.  Debuginfod is used by DebugInfo/Symbolize, so wouldn't we have to remove Symbolize from libLLVM.so as well? I imagine distros will want Symbolize if they ship with llvm's standard tools (including `llvm-symbolizer`).
I am curious about loading libcurl lazily via dlopen as Simon McVittie suggested on the mesa issue. Allowing this to happen with some build configuration would seem to meet the needs of a distro libLLVM.so, since it will still work fine for lldb, llvm-symbolizer etc. but mesa shouldn't pull in the conflicting curl (unless it uses debuginfod things).
I didn't completely understand the example of the failure case mentioned with Steam and libcurl 3 vs. 4. If curl is linked statically linked, I'm not sure why a particular version would be needed in the library search path in the first place, so Steam could have its favorite version there instead. Sorry if I'm misunderstanding something.

Anyways if it does address the problems I would lean towards adding a build option to pull in libcurl as a shared lib. Do you think this should be a follow-up diff?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D115500/new/

https://reviews.llvm.org/D115500



More information about the llvm-commits mailing list