about the "Attempt to fix stdint/cstdint modules try 2" commit

Hello,

I have a question about the commit that should help prevent errors building boost headerfiles (https://github.com/llvm-mirror/libcxx/commit/6010dc84c66ee4b30b4ffea34b0d1c616d04239b#commitcomment-22132510).

I'm seeing the issue reported in http://stackoverflow.com/questions/41050942/clang-modules-interaction-with-std-iterator-and-boost-move-iterator-hpp , but (and this may be a bit delicate) I'm seeing it with a gcc 6.3 build I'm adapting (ok, tweaking) to use libc++ and the corresponding headers, on Mac OS X 10.9 .

If I understand the fix correctly, it addresses an issue that isn't in the system libc++ on that OS version, so how come I'm seeing it?

Should I not build g++ using the clang 4.0 C++ headers for now, or maybe make that tweak runtime-only and deactivate it while building g++ itself?

Thanks for any insights,

R.

Hello,

I have a question about the commit that should help prevent errors
building boost headerfiles (https://github.com/llvm-mirror/libcxx/commit/
6010dc84c66ee4b30b4ffea34b0d1c616d04239b#commitcomment-22132510).

I'm seeing the issue reported in http://stackoverflow.com/
questions/41050942/clang-modules-interaction-with-std-
iterator-and-boost-move-iterator-hpp , but (and this may be a bit
delicate) I'm seeing it with a gcc 6.3 build I'm adapting (ok, tweaking) to
use libc++ and the corresponding headers, on Mac OS X 10.9 .

Just to be clear, You're attempting to build GCC 6.3 using Clang, and
you've hacked up the GCC build so that it always uses libc++ instead of
libstdc++?
AFAIK the GCC build doesn't use Boost, so IDK how Boost is getting into the
mix.

If you meant that you're building something else (which uses Boost) using
GCC 6.3, that also doesn't make sense because GCC doesn't support Clang
Modules.

If I understand the fix correctly, it addresses an issue that isn't in the
system libc++ on that OS version, so how come I'm seeing it?

I would assume the issue *would* be present in the OS X's system libc++
installation, (assuming the system installation hasn't been updated to
include the fix, which it likely hasn't)

Should I not build g++ using the clang 4.0 C++ headers for now, or maybe
make that tweak runtime-only and deactivate it while building g++ itself?

Why are you forcing GCC to build against libc++ in the first place? What's
the benefit? Doesn't the build default to bootstrapping and using a
bootstrapped libstdc++?

Just to be clear, You're attempting to build GCC 6.3 using Clang, and
you've hacked up the GCC build so that it always uses libc++ instead of
libstdc++?

- I use clang for the initial bootstrap build (which is perfectly possible and nothing new), afterwards GCC builds itself. Multiple times.
- yes, I have a hack that causes the resulting compiler to use the c++ headers from clang, and libc++
- the hack is supposed to evolve into support for a `-stdlib` feature like clang has

Why are you forcing GCC to build against libc++ in the first place? What's
the benefit? Doesn't the build default to bootstrapping and using a
bootstrapped libstdc++?

GCC itself is built against its usual static copy of libstdc++ and family (in the end that works out more reliably).
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++.

AFAIK the GCC build doesn't use Boost, so IDK how Boost is getting into the
mix.

No, it doesn't. I ran into an issue building software using boost, and boost itself, when using the "libc++ enabled g++".
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 .

I would assume the issue *would* be present in the OS X's system libc++
installation, (assuming the system installation hasn't been updated to
include the fix, which it likely hasn't)

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).

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?

R.

"Attempt to fix stdint/cstdint modules try 2" commit"

>Just to be clear, You're attempting to build GCC 6.3 using Clang, and
>you've hacked up the GCC build so that it always uses libc++ instead of
>libstdc++?

- I use clang for the initial bootstrap build (which is perfectly possible
and nothing new), afterwards GCC builds itself. Multiple times.
- yes, I have a hack that causes the resulting compiler to use the c++
headers from clang, and libc++
- the hack is supposed to evolve into support for a `-stdlib` feature like
clang has

>Why are you forcing GCC to build against libc++ in the first place? What's
>the benefit? Doesn't the build default to bootstrapping and using a
>bootstrapped libstdc++?

GCC itself is built against its usual static copy of libstdc++ and family
(in the end that works out more reliably).
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++.

>AFAIK the GCC build doesn't use Boost, so IDK how Boost is getting into
the
>mix.

No, it doesn't. I ran into an issue building software using boost, and
boost itself, when using the "libc++ enabled g++".

Are you sure you were using g++ and not clang++ (via c++ or some other
weird symlink)?
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.

/Eric

Yes, and even if I had been, why would that have caused trouble if none of the clang versions I have on my system had any issue?

R

Please provide the full and exact error text you’re encountering, and the exact (and verbose) compiler invocation that caused it.

As well as the output of g++ --version.

I think you may have missed something. In my case the error compiling a Boost file was not caused by an issue in clang or libc++. It was caused by the fact that Boost did not take the fact into consideration that it was building with libc++ and the corresponding headerfiles. I didn't know that yet when I posted this thread.

The error was almost exactly the same (and about the same file) as the one reported in the StackOverflow post linked to in my original post (https://stackoverflow.com/questions/41050942/clang-modules-interaction-with-std-iterator-and-boost-move-iterator-hpp) except formatted the way GCC does.

I don't know if it's a coincidence that treating the libc++ headers as if they were libstdc++ headers leads to the same error , nor if it's important to figure that out.

R.

Please provide the full and verbose compiler invocation and the full output it generates.
That’s the only way I can help.

Also what version of Boost are you attempting to build?

That's the only way I can help.

Thanks for the offer, but at this point I don't need help anymore.

Also what version of Boost are you attempting to build?

Not the most recent version; 1.59.0 . I still have to verify if the current
version still assumes that libc++ can only occur together with clang.

R.