<div dir="ltr"><div dir="ltr"><div>Hi Steve,<br></div></div><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>The best way I've found is to use LLVM_LINK_COMPONENTS, which ends up calling llvm_map_components_to_libnames() underneath hood.</div></div></blockquote><div><br></div><div>I tried grepping for LLVM_LINK_COMPONENTS in my installed lib/cmake/llvm<br>directory, but I only see it used as a global variable. Should it also be<br>a function?<br><br>I see that symbol in AddLLVM.cmake and TableGen.cmake. In the former, it<br>appears in add_llvm_executable and add_llvm_library. The documentation I<br>linked to earlier states that add_llvm_library is an "internal" macro, so<br>I assume that it shouldn't be used by fully external client code? The uses<br>in TableGen.cmake don't seem relevant.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>The biggest pitfall is that lldWasm needs to be linked the same way so that both link against libLLVM.so or both not.</div></div><div>It's possible you're trying to work around issues in the way that lldWasm is linked...</div></div></blockquote><div><br></div><div>The workaround we found for the way lldWasm is linked is simply to add an<br>error message to fail early in this case. The main issue was that nothing<br>was stopping our users from falling into this trap.</div><div><br></div><div>Best,</div><div><br></div><div>Alex<br></div></div></div>