<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Jan 14, 2014, at 4:16 PM, Reid Kleckner <<a href="mailto:rnk@google.com">rnk@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jan 14, 2014 at 3:54 PM, Nick Lewycky <span dir="ltr"><<a href="mailto:nlewycky@google.com" target="_blank">nlewycky@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> A Module more or less corresponds to a single .o file, which makes storing<br>
properties like linker flags a bit unusual. (This is true regardless of whether<br>
you make it a first class property or use named metadata.) Could you explain<br>
why it belongs here?<br></blockquote><div><br></div><div>Unusual for ELF, but both MachO and COFF apparently have places to store linker flags. So, we have to float that through LLVM's Module. =/</div></div></div></div></blockquote><br></div><div>FYI, this is a new feature in Xcode5 called “auto linking”. It only works with dynamic libraries. So, there is no potential the chaos that pulling in archives (which can pull in archives) can lead to. </div><div><br></div><div>That also means the xcode linker will not need this new API to libLTO because libLTO (when merging and compiling bit-code to mach-o) can just produce a mach-o file with the load commands that tells the linker which dynamic libraries to link with.</div><div><br></div><div>-Nick</div></body></html>