<br><br><div class="gmail_quote">On Sun, Dec 11, 2011 at 2:19 PM, Rafael Ávila de Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On 08/12/11 03:56 PM, Ivan Krasin wrote:<br>
> Hi llvm team!<br>
><br>
> I'm currently working on the extended version of llvm-ld, which has an<br>
> ability to check if all the symbols present (and fail if some symbols<br>
> are not resolved), treat archives in the right way (link all the object<br>
> files in the archive if it's specified as the regular input, not as -l)<br>
<br>
</div>Is that the "right way"? I think all native linker require a<br>
--whole-archive or similar to do that, no?<br></blockquote><div>My mistake. Please, read the phrase as "support -whole-archive".</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
> and the most important to my project feature: to link against bitcode<br>
> "shared objects". The semantics is pretty simple. The module treated as<br>
> shared object is only used as the source of symbol names which be<br>
> excluded from the list unresolved symbols.<br>
<br>
</div>In summary, linking foo.bc and bar.bcso (do you use a different<br>
extension to differentiate from a "static" bc?) would be equivalent (but<br>
faster, easier) to<br>
<br>
$ llc bar.bc -filetype=obj -o bar.o<br>
$ clang -shared -o bar.so bar.o<br>
$ clang -use-gold-plugin foo.o bar.so -o t<br>
<br>
Is that correct? In particular, "lld t" should show a dependency on bar.<br>
Any particular reason for not adding this to the plugin api?<br></blockquote><div>The result is a native .so here. My goal is to have a bitcode result.</div><div><br></div><div>gold plugin with mods supports that as well, but it would be nice to avoid dependency on gold and gold plugin to simplify things.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
> I feel like the similar functionality might be useful for other projects<br>
> as well. For example, Emscripten (as of 3 months ago, when I have<br>
> checked it) does not check for undefined symbols at link time, because<br>
> it does not have a way to link against glibc (the symbols from which<br>
> would be added at runtime as usual javascript functions). This adds<br>
> additional overhead to the developer who ports the software to<br>
> javascript using Emscripten.<br>
<br>
</div>Is that the same case? It seems that it would be easier to just include<br>
a stub ELF libc.so with the symbols from libc that Emscripten supports.<br></blockquote><div>I believe that Emscripten does not use gold and gold plugin at the moment. They use llvm-link: <a href="https://github.com/kripken/emscripten/wiki/Building-Projects" style="background-color:transparent" target="_blank">https://github.com/kripken/emscripten/wiki/Building-Projects</a></div>
<div><span style="background-color:transparent"><br></span></div><div><span style="background-color:transparent">I fully agree that all the features I want from the bitcode linker may be achieved with gold + gold plugin (with mods to both parts), but I would like to stay away from this dependency. Partly, because maintaining modified gold and gold plugin is no fun, partly because gold + gold plugin is hardly broken under cygwin. See </span><a href="http://code.google.com/p/nativeclient/issues/detail?id=2286" style="background-color:transparent">http://code.google.com/p/nativeclient/issues/detail?id=2286</a> for more details. In short, it's because cygwin does not fully support dlopen. <a href="https://www.google.com/search?sourceid=chrome&ie=UTF-8&q=cygwin+dlopen" style="background-color:transparent">https://www.google.com/search?sourceid=chrome&ie=UTF-8&q=cygwin+dlopen</a></div>
<div><br></div><div>It may be fixed by linking gold plugin to gold statically, like here: <a href="http://codereview.chromium.org/8713008/" style="background-color:transparent">http://codereview.chromium.org/8713008/</a> but it only adds the complexity.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
> Any objections? Comments?<br>
><br>
> Ivan Krasin<br>
<br>
</div>Cheers,<br>
Rafael<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</blockquote></div><br>