<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri",sans-serif;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">LLD claims that their design choice here actually improves link time: see “Efficient archive file handling” on
<a href="http://lld.llvm.org/NewLLD.html">http://lld.llvm.org/NewLLD.html</a>. Agreed on the circular dependence con.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black">cfe-dev <cfe-dev-bounces@lists.llvm.org> on behalf of cfe-dev <cfe-dev@lists.llvm.org><br>
<b>Reply-To: </b>"bcain@codeaurora.org" <bcain@codeaurora.org><br>
<b>Date: </b>Tuesday, April 2, 2019 at 3:49 PM<br>
<b>To: </b>'Louis Dionne' <ldionne@apple.com>, cfe-dev <cfe-dev@lists.llvm.org><br>
<b>Cc: </b>'TheAspiringHacker' <TheAspiringHacker@protonmail.com><br>
<b>Subject: </b>Re: [cfe-dev] [libcxx-dev] Is the C++ filesystem object file installed via LLVM's APT repository missing symbols?<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal" style="text-indent:.5in">This is the intended design of GNU ld. Some linkers follow this behavior, some don’t. e.g. IIRC lld chose to have an implicit grouping (like ld’s start-group/end-group), which comes w/pros and cons. Pros: like
you said, you needn’t concern yourself with the order of the libs. If you are consuming several different libraries, one could see the perspective that from up here at the executable’s perspective, you don’t care how the linker does symbol resolution and
one could imagine that it might not even matter that it takes more time for it to go and search the ones that appear earlier on the command line. Cons: increased link time, cyclical dependencies among libraries are easy to introduce now because the linker
won’t alert you to the problem.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Relevant details from the ld.bfd manpage:<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">--start-group archives --end-group<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"> <o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">…<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">The specified archives are searched repeatedly until no new undefined references are created.
<i>Normally, an archive is searched only once in the order that it is specified on the command line. If a symbol in that archive is needed to resolve an undefined symbol referred to by an object in an archive that appears later on the command line, the linker
would not be able to resolve that reference.</i> By grouping the archives, they all be searched repeatedly until all possible references are resolved.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">Using this option has a significant performance cost. It is best to use it only when there are unavoidable circular references between two or more archives.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-left:5.5pt"><b>From:</b> libcxx-dev <libcxx-dev-bounces@lists.llvm.org>
<b>On Behalf Of </b>Louis Dionne via libcxx-dev<br>
<br>
<br>
<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal">To clarify, what I meant is that from a very naive point of view, the order in which you provide `-l`'s on the command line shouldn't matter -- it should work as long as you provide the right set of `-l`'s. I'm puzzled every time a tool
(e.g. `ld`) behaves differently based on the order of command line arguments.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Maybe there's a good reason for this, though. Maybe the cfe-dev folks can explain?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Louis<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
</div>
</body>
</html>