<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=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@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;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@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>When using the ARM cross compiler we’ve run into an issue with LTO and optimized libraries.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Consider you have an optimized library opt.a, which contains a version of memcpy.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Compiling with LTO (something like),<o:p></o:p></p><p class=MsoNormal>clang myTest.c opt.a –flto –o myTest<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>causes myTest.c to get compiled to bitcode.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Then the bitcode gets passed to the linker. The linker looks through the bitcode (via the gold plugin) searching for symbols it needs to resolve. But any memcpy() calls in myTest.c got converted to llvm.memcpy() calls in the bitcode. Any symbols that start with ‘llvm.’ get ignored in LTOModule.cpp. So the linker doesn’t know that it needs memcpy. Now once the linker processes opt.a it doesn’t know that it needs memcpy, so the linker doesn’t keep the definition of memcpy from opt.a. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>After the (full) compilation of myTest is complete, the linker winds up trying to pull memcpy from libc. But once it hits opt.a to process again, it sees a multiple definition issue. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>It appears that optimized libraries and LTO don’t currently mix well. Does anyone have any insight about how this should be accomplished?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Daniel<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>--<o:p></o:p></p><p class=MsoNormal>Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p></div></body></html>