<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 14, 2019 at 4:34 PM Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> wrote:</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 class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 14, 2019 at 6:08 AM bd1976 llvm via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></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 dir="ltr"><div>The linker will process the .autolink strings in the following way:<br></div><div><br></div><div>1. Inputs from the .autolink sections of a relocatable object file are added when the linker decides to include that file (which could itself be in a library) in the link. Autolinked inputs behave as if they were appended to the command line as a group after all other options. As a consequence the set of autolinked libraries are searched last to resolve symbols.</div><div>2. It is an error if a file cannot be found for a given string.</div><div>3. Any command line options in effect at the end of the command line parsing apply to autolinked inputs, e.g. --whole-archive.</div></div></div></blockquote><div><br></div><div>I thought that the scope of this mechanism is essentially to add `-lfoo` automatically to the command line if you include a header that requires `libfoo`. >From that perspective, the item 3 seems odd. Why do you need that?</div></div></div></blockquote><div><br></div><div>I replied to Peter already on this; but, what I'm basically saying is that if you had a command line like...</div><div><br></div><div>bob.o --whole-archive -lbar</div><div><br></div><div>... and bob.o was built with #pragma comment(lib, "foo"), then this effectively is transformed into...</div><div><br></div><div>bob.o --whole-archive -lbar -lfoo<br></div><div><br></div><div>...and the --whole-archive applies to the -lfoo. The alternative that you use some defaults when handling the autolinked libraries.</div><div><br></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 class="gmail_quote"><div><br></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 dir="ltr"><div>4. Duplicate autolinked inputs are ignored.</div></div></div></blockquote><div><br></div><div>I'd say duplicate autolinked inputs are processed normally, but because of the same reason why  the second parameter in `-lfoo -lfoo` is basically no-op, duplicated autolinked inputs are naturally ignored.</div></div></div></blockquote><div><br></div><div>Again, replied to Peter - .o files and I also want to leave the door open for GNU to be able to implement this.</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 class="gmail_quote"><div><br></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 dir="ltr"><div>5. The linker tries to add a library or relocatable object file from each of the strings in a .autolink section by; first, handling the string as if it was specified on the commandline; second, by looking for the string in each of the library search paths in turn; third, by looking for a lib<string>.a or lib<string>.so (depending on the current mode of the linker) in each of the library search paths. </div></div></div></blockquote><div><br></div><div>Again, this seems like a little beyond the scope of what I expect (and it looks like you want to allow an .o file using this scheme).</div></div></div></blockquote><div><br></div><div>Again, replied to Peter. I think that .o files should be included, --library allows this.</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 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 dir="ltr"><div>6. A new command line option --no-llvm-autolink will tell LLD to ignore the .autolink sections.</div><div><br></div><div>Rationale for the above points:</div><div><br></div><div>1. Adding the autolinked inputs last makes the process simple to understand from a developers perspective. All linkers are able to implement this scheme.</div><div>2. Error-ing for libraries that are not found seems like better behavior than failing the link during symbol resolution.</div><div>3. It seems useful for the user to be able to apply command line options which will affect all of the autolinked input files. There is a potential problem of surprise for developers, who might not realize that these options would apply to the "invisible" autolinked input files; however, despite the potential for surprise, this is easy for developers to reason about and gives developers the control that they may require.</div><div>4. Unlike on the command line it is probably easy to include the same input file twice via pragmas and might be a pain to fix; think of Third-party libraries supplied as binaries.</div><div>5. This algorithm takes into account all of the different ways that ELF linkers find input files. The different search methods are tried by the linker in most obvious to least obvious order.</div><div>6. I considered adding finer grained control over which .autolink inputs were ignored (e.g. MSVC has /nodefaultlib:<library>); however, I concluded that this is not necessary: if finer control is required developers can recreate the same effect autolinking would have had using command line options.</div><div><br></div><div>Thoughts?</div><div><br></div></div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>
</blockquote></div></div>