Using Libstdc++ Compiled Libraries with Clang++ -Stdlib=Libc++

With clang and libstdc++ on Linux, is it currently feasible to use any standard library types in a module interface?

Ok, this is something that sort of worked for a large project. Note that this was half a year ago, so the world may have moved on.

I ended up creating a single header, "sys.hh", that #includes pretty much all the system headers used in the project. What seems to be important is that nothing directly or indirectly #included by this file gets #included directly or indirectly (outside the module system) in anything that gets linked into the final binary.

My "sys.hh" looks something like this:

#include <algorithm>
#include <array>
#include <assert.h>
#include <atomic>
#include <bits/std_abs.h>
// 100+ lines omitted, including things like glib, gtk, libjpeg
#include <vector>
#include <x86intrin.h>
#include <zlib.h>

// Macros won't get exported, so whatever the code needs, redefine as
// constexpr (or consteval functions) here. Unfortunately, I don't think
// there's a way to retain the name of the macro; so add an underscore.
// Also put them in a namespace.
#define MEXP(X) constexpr auto X ## _ = X;

namespace sys {
    MEXP(INTENT_PERCEPTUAL);
    MEXP(INTENT_RELATIVE_COLORIMETRIC);
    MEXP(INTENT_SATURATION);
    MEXP(INTENT_ABSOLUTE_COLORIMETRIC);
    MEXP(G_PRIORITY_DEFAULT_IDLE);
}

And my my modulemap file contains an entry like this:

module sys {
    header "prebuilt/sys.hh"
    use _Builtin_intrinsics
    export *
}

Compiling this header/module is a bit of an incremental process; you will run into modules that fail to compile because they indirectly include the same headers, so you add them into this file and rebuild until it works.

Note that managing build dependencies becomes much more of a thing with modules. At least half a year ago no good (automatic) ways seemed to exist to discover what needs to be rebuilt. This is made trickier by the fact that the name of the module does not tell where it lives in the source code.

Building Clang, libstdc++4.6 to libstdc++4.7

I ran into the same problem. The easiest way to build Clang is to use libc++ instead of libstdc++. If you don't have libc++, you can obtain it by installing XCode 4.2 (or newer) or you can build it yourself by following the instructions here: http://libcxx.llvm.org/

After you have libc++ installed, you can use the --enable-libcpp=yes flag with the configure command.

Clang refuses to compile libstdc++'s filesystem header

The issue can be fixed by patching <msys2_path>/mingw64/include/c++/9.2.0/bits/fs_path.h.

At lines 666-692, there is a definition of class filesystem_error. It has to be moved up to line 614, to be right above the definition of u8path().

---

I think it's a libstdc++ bug. I've reported it here.

class filesystem_error is used several times in bits/fs_path.h, and every use of it is below the definition, except for the problematic line 636.

That line is wrapped in #ifdef _GLIBCXX_FILESYSTEM_IS_WINDOWS, so I guess the Clang developers don't run libstdc++ compatibility tests on Windows.

---

UPD: This is fixed in GCC 9.3.

---

Related Topics