<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 25, 2017 at 1:41 AM, René J.V. Bertin <span dir="ltr"><<a href="mailto:rjvbertin@gmail.com" target="_blank">rjvbertin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Eric Fiselier wrote on 20170524::21:58:56 re: "Re: [cfe-dev] about the "Attempt to fix stdint/cstdint modules try 2" commit"<br>
<span class=""><br>
>Just to be clear, You're attempting to build GCC 6.3 using Clang, and<br>
>you've hacked up the GCC build so that it always uses libc++ instead of<br>
>libstdc++?<br>
<br>
</span>- I use clang for the initial bootstrap build (which is perfectly possible and nothing new), afterwards GCC builds itself. Multiple times.<br>
- yes, I have a hack that causes the resulting compiler to use the c++ headers from clang, and libc++<br>
- the hack is supposed to evolve into support for a `-stdlib` feature like clang has<br>
<span class=""><br>
>Why are you forcing GCC to build against libc++ in the first place? What's<br>
>the benefit? Doesn't the build default to bootstrapping and using a<br>
>bootstrapped libstdc++?<br>
<br>
</span>GCC itself is built against its usual static copy of libstdc++ and family (in the end that works out more reliably).<br>
The benefit of my approach is simple and sufficiently obvious that the GCC team will consider the change once implemented properly. It's the only way G++ can be used on systems that use libc++ as the system C++ runtime without taking extreme precautions. It's not impossible to run binaries that use the libstdc++ runtime on Mac, but in practice they should not use any system SDKs that are written in C++, to avoid passing objects between libc++ and libstdc++.<br>
<span class=""><br>
>AFAIK the GCC build doesn't use Boost, so IDK how Boost is getting into the<br>
>mix.<br>
<br>
</span>No, it doesn't. I ran into an issue building software using boost, and boost itself, when using the "libc++ enabled g++".<br></blockquote><div><br></div><div>Are you sure you were using g++ and not clang++ (via c++ or some other weird symlink)?</div><div>GCC doesn't support Clang Modules (e.g. module maps), so you can't have been running into a modules if you were using GCC 6.3.</div><div><br></div><div>/Eric</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I've had the time to look into this further since asking here, and discovered that Boost has a number of places where it assumes that libc++ is used only together with clang. When I patched those the issues went away, at least on OS X 10.9 .<br>
<span class=""><br>
>I would assume the issue *would* be present in the OS X's system libc++<br>
>installation, (assuming the system installation hasn't been updated to<br>
>include the fix, which it likely hasn't)<br>
<br>
</span>No, I haven't updated the system libc++. I have a more recent libc++ installed to the side (from the MacPorts package) which I insert into applications I run from a shell, but that doesn't help with anything that sneaks in at link time (or is run via the Finder).<br>
<br>
But if I understand correctly the issue is relatively recent, and should thus not yet be present in installations that are now several years old, correct?<br>
<span class="HOEnZb"><font color="#888888"><br>
R.<br>
<br>
</font></span></blockquote></div><br></div></div>