<p><span class="h-card" translate="no"><a href="https://mastodon.social/@whitequark" class="u-url mention">@<span>whitequark</span></a></span> Yeah there used to be a few ye olde binaries that lived in /etc.</p>

<p><span class="h-card" translate="no"><a href="https://mastodon.social/@mcc" class="u-url mention">@<span>mcc</span></a></span> yes that is what seems to be happening to me</p><p>i.e. servo _absolutely requires_, for whatever goddamn reason, the nongnu/hp libunwind</p><p>in this case trying to shove any other libunwind into that hole will likely not work</p>

<p><span class="h-card" translate="no"><a href="https://mastodon.social/@whitequark" class="u-url mention">@<span>whitequark</span></a></span> Everything is being built from source. However there may be a Rust-&gt;C language boundary being crossed, which may look like &quot;expecting the nongnu/hp libunwind&quot; from that side.</p>

<p><span class="h-card" translate="no"><a href="https://mastodon.social/@mcc" class="u-url mention">@<span>mcc</span></a></span> do you desire assistance</p>

<p><span class="h-card" translate="no"><a href="https://mastodon.social/@mcc" class="u-url mention">@<span>mcc</span></a></span> if you are linking something that expects the nongnu/hp libunwind against libgcc_s or llvm libunwind it will simply not work. i think the llvm libunwind includes _some_ amount of compatiblity but nobody uses that</p>

<p><span class="h-card" translate="no"><a href="https://mastodon.social/@mcc" class="u-url mention">@<span>mcc</span></a></span> llvm libunwind is essentially an internal component of the platform runtime. it is documented in the Itanium (EH)ABI.</p><p>the other libunwind you&#39;re dealing with is some other thing with the same name that&#39;s unrelated except for its purpose</p><p>libgcc_s and llvm libunwind implement the same interface and are mutually exclusive; the other libunwind could be used together with each</p><p>does this clarify</p>

<p>Now I get to uninstall the libc from my computer completely and replace it with a different one. Because it&#39;s the only remaining way to fix this linker error.</p>

<p>I lose <a href="https://mastodon.social/@mcc/113807871925781727" target="_blank" rel="nofollow noopener" translate="no"><span class="invisible">https://</span><span class="ellipsis">mastodon.social/@mcc/113807871</span><span class="invisible">925781727</span></a></p><p>This is the limit of my ability to debug. I cannot work out why an undocumented function, whose name begins with an underscore, from library A is not being provided by a library B which has no documentation at all, when building someone else&#39;s code that I do not know the purpose of. I lose! I thought I could just keep powering through build errors but now.</p>

<p><span class="h-card" translate="no"><a href="https://chaos.social/@ReneRebe" class="u-url mention">@<span>ReneRebe</span></a></span> <span class="h-card" translate="no"><a href="https://chaos.social/@esden" class="u-url mention">@<span>esden</span></a></span> <span class="h-card" translate="no"><a href="https://social.1bitsquared.com/@1bitsquared" class="u-url mention">@<span>1bitsquared</span></a></span> yeah, we should be getting that out of SFDP...</p>