<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Issue</th>
<td>
<a href=https://github.com/llvm/llvm-project/issues/57781>57781</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>
LLVM_ENABLE_RUNTIMES don't always match search paths for runtimes
</td>
</tr>
<tr>
<th>Labels</th>
<td>
</td>
</tr>
<tr>
<th>Assignees</th>
<td>
</td>
</tr>
<tr>
<th>Reporter</th>
<td>
sztomi
</td>
</tr>
</table>
<pre>
https://github.com/llvm/llvm-project/issues/54196 was closed with band-aid fix for a release, but the issue is more generic than that. So I'm opening this instead.
The search paths for runtimes (`clang -print-runtime-dir`) and the CMake code don't agree on when to normalize the triple. clang always normalizes, but CMake just appends the literal triple as it was passed to the build. This can break distribution builds.
That in turn causes a hard to debug issue in new-layout builds when the canonical triple differs from the literal triple. A confusing error that references the old layout will be displayed because that's the last fallback. The only viable solution is symlinking the literal triples to the normalized forms in all places.
There are a couple of ways to solve this (as discussed on Discourse and Discord):
* Compute the normalized triple at CMake configure-time and use that instead of the literal triple passed
* @petrhosek proposed using the stage1 compiler to do this (I think he also began implementing this). This is probably a good solution for 99% of distribution builds because I doubt that anyone builds a single-stage compiler for production use.
* Another option is compiling a tiny executable at CMake configure-time that can compute the normalized triple. Unfortunately this requires pretty much the entire libSupport so it's a lot more than tiny. The core logic for this is Triple.cpp and I could imagine some ways of extracting that without depending on libSupport, but it's probably far too involved with little extra benefit (compared to the above solution).
Additionally, it would be useful if there were some ways to get some insight into the fallback mechanism, similarly to how library search paths can be printed (i.e. "we tried these paths, they didn't work; finally used this fallback which also failed"). But this is only a QoL improvement.
Previous discourse threads:
* https://discourse.llvm.org/t/triple-quirks-for-finding-runtimes-how-to-improve-this/64078
* https://discourse.llvm.org/t/handling-version-numbers-in-per-target-runtime-directories/62717
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJylVsuS2zYQ_BrqgqJKol6rgw5aP6q2au1K4nWuLpAYUrBAgAFAyfLXpwfUY3ezziGpWtPiAzM93T0DlE6dNrsYu5DNtlnxEX-Njru-HFeuxY0xh8t_eefdd6oibnUIPQX8WMyn66U4yiAq4wIpccRiUUqrcqmVqPUPUTsvpPBkSAbKinei7KOIOxIpCK6idZ5EQ5a8rvBGWr7EsfjixENWrFrhOrLaNniMr7UNkaQaZ5P32WQ7XJ8QLpD01U50Mu5CSup7G3VLQWTFXbacVEYiBIrQNubnd7nSHq-yYi0AOaF690nuSVROkVDOIn0UsvFEwllx3BGwOWGdb6XRPymtiF53hsZiSCDNUZ7C7ZNwKXkI_L0PCNihIBXSaqMjeWnOUQSY1DER2snAhCIdf1b22qixeGIGKjBUepJ7oXTAOkTXQJc-CWPxkhgZwZiIvbdY1wfQIcVO-hRYUdk3Fx2ssHTMjTw5gB1inQtGeqR0Vlc3nErXNXkQ7V37Rh1jsQWHtu4D60beQw8WFT7AMrIVDdU7o8Q55VEbI0qOHDo8QuklJcRpIYQ48yVBYC2NKWW1Z0JYGXMSBy1L4ArODGyAp3Bqjbb7wTmvEYYLs1elFLumZYNBRCMAAihf2wxOlfwP1fXMg6tF0hvBkPpAg0fhOCiISqo-iQg873Hjeo9y2GnpzisYj9vuWQqBtVvxzrVdH-k1votH4tWlttZN7ylnM6fAF74ubcIA37DZYK5LyiFpNp90FP0OfbwX6PUuNfSgIIcIUTY0RdK204Z8MpC71vvAv-xe4ENpgoN4DWyqW2RrCc12bl9UfHYx_pCkhGon0Nk4p27icfuu11mxYPhvmPxqjQdA6Ms4lCztyVm6fCIFIzeUJ9w32BwbiVVfpYCIMn7Jw9Y6lOsxdS5GGtZyCVKgkpOgH1T1MRnuV2IkRNyp1b9pORZfLQDF3spIICKx6emvXntifijGk2h7zDVezjx61rL80ncdloExjIvUG1IYF4dROoxQ4Bzao-JnxjUYrnVqw4H8pwFA1XXJOA_saHSjbmWjLTcSikjWhgT0I3pZnUWUMU157llFPMj4MYi6wbqMvDO0q8y1ZNcAsj1wr5x3C1gzgsiUA8JaqjEB4SgmDr12HYGydIdbg7ORnjfOVinNz9G6J87PUzQVhJECjeveCJ1aAWQc-XIrEPEbisMDtI1udtw-56yXUSNaqsCrDi1HD7rVRnpWzImdO3LxXvrTy10oDWo0G285qAM16TEkz4rimLYNSltOoOFzjovbEwyvho3n6Pw-m91jG01lcR1q0O-K6rjTSJc6rpbwN0ZKkXrsPu2yg9RpQErxu3vkhvSgkVvyBX2_eTpo1w9Da5hTcYc9RoU3B9TLE8N1zZjPCWPnGzzkc8Jg8pztvA853JejFPbLZQMOOcjLo8vPuPJhRnxczieru_-QEAopbtT8gM0Jbsht35b4mWubd-TzKD2kfr7940DjoERKWqymq-e1_vM6os10uZzNZtP5fDVSm5laz9ZyFDUcvHl8_PPTtw-ft_ePH7798fXz08OnD19uh4jhXNDKCL1-eVYZ9d78n-PYanU3He02spjNl8v14m5SLKuiXs7rNakpLUiWeFitRkaWZMImW9xni_cjvSkmRTFZT5fTYjaZr8aqLO8qmq-narkoFuUKWwO1sNeV7pHfJAw4PwS8NBjR4fYSm4tuLNElvuwxLvwm_Iyu1aOEdpOg_g0xb6Mh">