<div dir="ltr">Hi Renato,<div><br></div><div>> <span style="font-size:12.8px">Do you mean only libsupc++ or the whole libstdc++?</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">I think David meant that by default, libsupc++ is only provided by way of libstdc++.so and we can't control that. For that reason it's best to link against the whole libstdc++.so so we can get libsupc++.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">> </span><span style="font-size:12.8px">Erik's proposal will break if </span><span style="font-size:12.8px">it includes either libsupc++ or libc++abi.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">I'm a bit confused. My proposal can deal with both libsupc++ and libc++abi. Could you elaborate on the issues you see?</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 14, 2015 at 4:36 AM, Renato Golin <span dir="ltr"><<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 12 October 2015 at 12:19, David Chisnall via cfe-dev<br>
<span class=""><<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
> If you can not modify the linkage of libstdc++ on your target platform, then the best solution is to use libstdc++ itself as the ABI library.<br>
<br>
</span>Do you mean only libsupc++ or the whole libstdc++?<br>
<br>
Back to Erik's proposal, the clang driver had some similar logic to<br>
Compiler-RT that was added and removed by me given the solutions and<br>
complications I found.<br>
<br>
>From compiler-rt, on GNU systems, I added libgcc_s or libgcc_eh<br>
automatically, so one could use "--rtlib=compiler-rt" and get<br>
everything working out of the box. But that breaks out when you want<br>
to use libunwind, in the exact same way Erik's proposal will break if<br>
it includes either libsupc++ or libc++abi.<br>
<br>
Not controlling the base architecture is a problem, given that all<br>
your dynamic objects already link and use whatever the platform gives<br>
you. This takes us back to the drawing board.<br>
<br>
What do we want from our high level libraries?<br>
<br>
* Independent, good quality libraries? In which case testing<br>
compatibility with other base libraries is unnecessary and all we test<br>
are statically linked (or controlled dynamically linked) environments.<br>
<br>
* Inter-operational, sometimes redundant libraries? In which case we<br>
assume the target always has libgcc / libsupc++ and only ever replace<br>
compiler-rt and libc++, not the other two.<br>
<br>
I believe both solutions have huge problems, but I can't see the few<br>
of us actually supporting *well* both use cases at the same time.<br>
<br>
Ideas?<br>
<br>
cheers,<br>
--renato<br>
</blockquote></div><br></div>