C++20 modules with GCC11

Posted on August 18, 2021 by Niall Cooling

Introduction

One of the headline changes of the C++20 standard is the inclusion of modules. Modules promise to significantly change the structure of C++ codebases and possibly signal headers’ ultimate demise (but probably not in my lifetime). It also opens the door to potentially have a unified build system and package manager, similar to Rust’s Cargo package manager; though I imaging standardising a unified build system would be one bloody battle.

Pre-C++20 builds

If you want to start a heated debate on any C++ forum/channel, just state that one particular build system (e.g. Meson, CMake, Bazal, etc.) is better than the others; or that your way of using that build system is the “one, and only one, correct way”. If you are unfamiliar with build systems, I’d recommend reading this post first to understand the challenges.

Start with the Why

There have already been several articles written about Modules (significantly by Microsoft ). But my experience, in reading these, is that they focus ‘how’ modules work in C++20 and seem to miss the ‘Why’. Maybe the authors consider it obvious, but I think it depends on your background. In addition, all I have read use Microsoft MSVC, due to this having the fullest support for Modules among the mainstream toolchains.

First and foremost, when discussing modules, surely, we should be discussing modularity. We already have one form of modularity in C++ with the object/class model. But this is modularity ‘in the small’; modules are addressing ‘modularity in the large’, i.e., program-wide modularity.

So What problem are we trying to solve by adding modules?

Let’s be honest, “Headers are a mess” – they can (and have for many decades) been used effectively, but so often, I see very poorly constructed headers (IMHO). A well-crafted application will, typically, have pairs of files to “mimic” a module, e.g., file.h and file.cpp. But there is no enforcement of this approach; we also need to understand external- and internal-linkage rules to build a modular architecture safely.

The root of the problem with headers is they only exist up to and including pre-processing:

Headers do not exist during the compilation phase

We could happily (okay, maybe not happily) write a complete C++ application without any headers. There would be a lot of code duplication (declarations), and it would be a maintenance nightmare, but that’s how the current build model works (it all stems from the definition of a translation unit).

Modularity (in the large) is typically closely related to application architecture and construction – the files that make up our build.

Before we go on, I need to stress one important aspect – Modules and Namespaces are entirely orthogonal and co-exist as independent aspects (more on this later).

Other languages

Many modern languages tend to build the semantics of a module around all the code for the module existing within a single file, e.g. Java and Python

They have the concepts of exporting and importing types and behaviours from other modules. It is very similar to the public/private semantics of the class but at the file scope.

Interestingly, older languages, such as Ada and Modula-2, designed in the 1980s, around the same time as the original C++, use a two-file structure for defining modules (or packages in Ada’s case). These designs separate the module interface from the implementation.

The significant benefits of the interface/implementation file structure can be:

Improved build times
Simplified integration and testing

Though, of course, this is another hotly debated subject.

C++20 Module File Structure

Dare I say it, but C++ being C++, rather than a straightforward way of structuring models (a.la. Java), we have been given the suiss-army-knife approach to module construction. There are numerous ways of doing the same thing and lots of special cases. This, initially, caused me a lot of problems as my mental model (based on other language paradigms) wasn’t aligning with what I was being introduced to.

There is no one way of correctly using C++20 modules

I’m sure, over time, we will come up with new idioms regarding the use of modules, but for now, I can see three obvious uses of modules (think 80:20 rule)

Single file module – the Java/Python model or a complete module
A separate Interface file and Implementation file for a module – the Ada model
Multiple separate files (partitions) combining to define a single module concept – the C++20 model

In C++20, any file containing the module syntax is referred to as a Module Unit. Therefore a Named Module may be made up of one or more Module Units.

Single-file (Complete) Module

Pre-C++20 code

Let’s start with the obligatory “hello, world!” example, splitting the behaviour across two files.

Remember

At compilation headers don’t exist

We have two files, func.cpp and main.cpp

// func.cpp
#include <iostream>

void func() {  // definition
    std::cout << "hello, world!\n";
}

// main.cpp
void func();  // declaration

int main(){
    func();
}

We can go ahead and build and run the application:

$ g++ -c func.cpp 
$ g++ -c main.cpp 
$ g++ -o App main.o func.o
$ ./App 
hello, world!

This, of course, builds successfully as the function func has, by default, external linkage (often referred to as global scope). So as long as main has a valid declaration, the main.cpp file can be compiled, and the linker resolves the exported/imported symbols.

C++20 Module

The early proposals for module support, P1103R3, uses the term complete module where

A complete module can be defined in a single source file.

I quite like this term, and therefore I’m going to use it for single-file modules (until something better comes along).

First, we need to create our Named module. A complete module file will, typically, have two, possibly, three sections (called fragments)

A global module fragment – this is where we include things we need (optional)
The main module purview – Where we can export types and behaviour
A private fragment – this ends the portion of the module interface that can affect the behaviour of other translation units (optional).

The private module fragment can only appear in single-file modules. The current version of GCC (gcc version 11.1.0) does not support private fragments, so I’m not going to ignore them for this post.

The C++ standard does not define file extensions; this is toolchain specific. With GCC, the file name suffix determines how the file is treated for any given input file.

GCC interprets the following file extensions as C++ source code which must be preprocessed:

file.cc
file.cp
file.cxx
file.cpp
file.c++
file.C

We have always preferred the .cpp extension for C++ source files in our projects and when teaching C++. So to that end, in the following examples, I will use .cpp for regular C++ source files and .cxx for module files. This is nothing more than a personal preference.

Notably, Microsoft has chosen to use the extension .ixx for module interfaces (see link). We could use file.ixx but, with GCC, would need to use the -x c++ file.ixx directive to specify the file should be treated as a C++ file. Rather than use the additional complication, using .cxx means it will be treated as a standard C++ file by GCC.

To make the original file func.cpp into a module (func.cxx), we add the line

export module MODULE-NAME;

e.g.

// func.cxx
#include <iostream>

export module mod;

void func() {
    std::cout << "hello, world!\n";
}

However, this will not yet compile. The include statement needs to be in the global fragment. The global fragment must precede the main purview and is simply introduced using the keyword module, e.g.

// func.cxx
module;

#include <iostream>

export module mod;

void func() {
    std::cout << "hello, world!\n";
}

We can now import the module mod into main:

// main.cpp
import mod;

int main(){
    func();
}

Next we can compile func.cxx

$ g++ -c -std=c++20 -fmodules-ts func.cxx

Note, in GCC C++20, modules are, currently, not enabled by just specifying c++20; you must also supply the directives-fmodules-ts.

As expected, the compilation generates an object file func.o. However, you will also notice that a subdirectory, gcm.cache is created, with the file mod.gcm. This is the generated module interface file used by the compile.

If we go ahead and compile main.cpp

$ g++ -c -std=c++20 -fmodules-ts  main.cpp 
main.cpp: In function 'int main()':
main.cpp:5:5: error: 'func' was not declared in this scope
    5 |     func();
      |     ^~~~

We get the error that func was not declared. If we tried to declare it in main.cpp (as before) it would build but fail to link.

So this gives us our first significant change:

In modules, all declarations and definitions are private unless exported

Officially they have Module Linkage, which differs from internal linkage. This only becomes apparent when using a multi-file module and partitions (cover in the follow-on post).

To fix this, we export the function, e.g.

// func.cxx
module;

#include <iostream>

export module mod;

export void func() {
    std::cout << "hello, world!\n";
}

The project now successfully compiles and links:

$ g++ -c -std=c++20 -fmodules-ts func.cxx
$ g++ -c -std=c++20 -fmodules-ts main.cpp 
$ g++ main.o func.o -o App
$ ./App 
hello, world!

One final detail, we still can separate out a declaration from a definition, e.g.

// func.cxx
module;

#include <iostream>

export module mod;

export void func();

void func() {
    std::cout << "hello, world!\n";
}

I’m not sure this is of much benefit, but I guess comes down to style.

Separate Interface and Implementation files

At some point, or because of personal preference, we may choose to split our module into multiple files to make it more manageable and help rebuild times.

Each file pertaining to a module is called a Module Unit. We are going to create two units:

A Primary Module Interface Unit (PMIU)
A Module Implementation Unit

Primary Module Interface Unit

Each named module must have one, and only one, Primary Module Interface Unit. This is the revised file func.cxx that contains the statement:

// func.cxx

export module MODULE-NAME;

and our other export statements, e.g.


export module mod;

export void func();

That’s all we need; we have named a module mod that exports a single function func. We can go ahead and compile this unit:

$ g++ -c -std=c++20 -fmodules-ts func.cxx

As before, this generates func.o and gmc.cache\mod.gmc.

Module Implementation Unit

There currently is no idiomatic naming conversion, so I have gone with func_impl.cxx, but it could be any filename/extension you prefer. You cannot use func.ixx as it will also generate an object file func.o which will overwrite that func.cxx generated object file.

An implementation unit contains the line:

module MODULE-NAME;

Note it does not have the export keyword. This implicitly makes anything declared/defined in the PMIU available in the implementation unit (the opposite is not true). Note, implementation units cannot have any export statements.

// func_impl.cxx
module;

#include <iostream>

module mod;

void func() {
    std::cout << "hello, world!\n";
}

And there we have it. This implementation unit can now be compiled:

$ g++ -c -std=c++20 -fmodules-ts func_impl.cxx

Which generates func_impl.o – we have two module object files as part of our linkage, but of course, this also means the changes to the module implementation do not require a recompile of clients (mimicking the behaviour of included headers).

$ g++ main.o func.o func_impl.o -o App
$ ./App 
hello, world!

With GCC, the interface unit must be compiled before the implementation unit.

export

So far, we have only exported a single function. Assuming we have multiple functions, we want to export, the standard allows for several options.

Export per function

For each function we want to export, we simply prepend the export keyword to add it to the interface.

// func.cxx

export module mod;

export void func();
export void func(int);

Export block

Alternatively, we can group many declarations into an export block, e.g.

// func.cxx

export module mod;

export {
    void func();
    void func(int);
}

Namespace

As mentioned earlier, C++ namespaces are orthogonal to modules. Again, I will admit this initially also caused me some confusion. Not, in so much, as the syntax, more the general philosophy of using namespaces and modules; where each one fits in an architectural structure. This is possibly skewed by my early background in Ada, where the two (the package) very much align.

From a practical perspective, namespaces behave as before, so there is no real change to their use, e.g.

// func.cxx

export module mod;

namespace X {
    export void func();
    export void func(int);
}

// func_impl.cxx
module;

#include <iostream>

module mod;

namespace X {
    void func() {
        std::cout << "hello, world!\n";
    }

    void func(int p) {
        std::cout << "hello, " << p << '\n';
    }
}

// main.cpp
import mod;

int main(){
    X::func();
    X::func(42);
}

Export namespace

Alternatively, if we export a namespace, all declarations within that namespace are automatically included in the module’s interface, e.g.

// func.cxx

export module mod;

export namespace X {
    void func();
    void func(int);
}

Exporting Types, etc.

Anything we require as part of the module interface must be exported. For example, if function takes an object reference as a parameter, the normal type definition visibility rules apply, e.g.

// func.cxx
export module mod;

export class S {
public:
    S() = default;
    explicit S(int p):val{p}{}
    int get_val() const;
 private:
    int val{};
};

export void func(const S&);

// func.cxx
export module mod;

export  {
    class S {
    public:
        S() = default;
        explicit S(int p):val{p}{}
        int get_val() const;
    private:
        int val{};
    };

    void func(const S&);
}

// func_impl.cxx
module;

#include <iostream>

module mod;  // implicitly import everything in PMIU

void func(const S& ptr) {
    std::cout << "hello, " << ptr.get_val() << '\n';
}

int S::get_val() const {
    return val;
}

// main.cpp
import mod;

int main(){
    S s{10};
    func(s);
}

There are a whole host of rules and exceptions regarding exporting items, such as templates and ADL evaluation. I’m not going to get into those here as it becomes very use-specific.

Includes

In the example, we can see we’ve used the traditional preprocessor directive #include to include the standard library header iostream. The standard permits the following:

import <iostream>;
import "header.h";

This is supported by GCC11, but there are some hoops you have to jump through to first make a user-defined header importable (see the -fmodule-header directive).

If you have a header-only file, e.g.

// header.h
#ifndef _HEADER_
#define _HEADER_

constexpr int life = 42;

#endif

and you want to import; you first need to compile it, e.g.

$ g++ -c -std=c++20 -fmodule-header header.h

This generates a header.h.gcm file. The header can now be imported using the directive

import "header.h";

note the ;

In addition, Microsoft has already wrapped the standard library up in a module structure, so you may see the following:

import std.core

in Microsoft specific examples.

Summary

Hopefully, this will give you a feel for the foundations of C++20 modules and enough to go and experiment. I believe that the single-file and interface/implementation models will accommodate most people initial uses of modules.

In the follow-up post, I will cover the more complex ability to split a module’s interface into multiple files (called partitions). Using partitions, on the surface looks straightforward, but appears to open a pandoras’ box of fun and games.

My initial reaction to modules is that they are overly complex, but I put that down to my background and mental model having used module concepts in other languages. In addition, much of the coverage of modules does delve down into the complications of using partitions without laying out the basics.

I’m sure over the next couple of years, as support for modules improves, we’ll find an idiomatic approach to using modules; even if we can just get a consistent file naming convention.

In the deeply embedded space, we have only recently seen the release of GCC10 for Arm, so I can imagine it may be sometime before GCC11 can be used in our target project. Until then, I will continue to experiment with modules and partitions on the host.

The example code can be found here

Next post: C++20 Module Partitions

About
Latest Posts

Niall Cooling

Director at Feabhas Limited

Co-Founder and Director of Feabhas since 1995.
Niall has been designing and programming embedded systems for over 30 years. He has worked in different sectors, including aerospace, telecomms, government and banking.
His current interest lie in IoT Security and Agile for Embedded Systems.

Niall Cooling

Website | + posts

About Niall Cooling

Co-Founder and Director of Feabhas since 1995. Niall has been designing and programming embedded systems for over 30 years. He has worked in different sectors, including aerospace, telecomms, government and banking. His current interest lie in IoT Security and Agile for Embedded Systems.

View all posts by Niall Cooling →

This entry was posted in C/C++ Programming and tagged C++20, modules. Bookmark the permalink.

12 Responses to C++20 modules with GCC11

_rf says:

August 19, 2021 at 9:14 am

Just a heads-up while I've only read the introduction:

> I’d recommend reading this post first to understand the challenges.

seems to be missing a link 😉
[plus I kind of expected the "this" to be clickable too, I suppose?]

Like (2)

Dislike (1)
Niall Cooling says:

August 19, 2021 at 11:25 am

Thanks, added link

Like (0)

Dislike (0)
Paul Topping says:

August 20, 2021 at 8:32 pm

When I read that you were going to give us the "why?" of modules, I was overjoyed, but you never really got to it. I guess you suggested that it would reduce build times but many people do projects where build time is not that big an issue. Perhaps modules don't give much of an advantage except on very large projects. You mention that headers can be a mess but fail to mention how modules fixes this. Perhaps I just missed it.

To me, a module system implies that one can reduce dependencies among various parts of a larger program. If so, what dependencies are eliminated? I expect to see sentences of the form, "Now that we've broken our example program into several modules, I can change X, rebuild, and all the build system has to do is Y, which is much less than our example without modules." Am I expecting too much?

If this sounds harsh, I don't mean it to be. I imagine people working with modules are too close to them to see how hard it is for people like me to wrap their heads around them.

Like (7)

Dislike (0)
Niall Cooling says:

August 31, 2021 at 8:54 am

Hi Paul,
Thanks for the feedback. In retrospect you're right (constructive criticism is always welcome) - I didn't bring out the "why" clearly enough.
In terms of Software Engineering, then the most important change is defaulting of module linkage to "private" over "public". This should help reduce module coupling (see our webinar for further coverage). It may seem trivial, but it ideally forces the module designer to actually think about "why" an artifact is being exported. This, in itself, won't stop poor software (or to that matter really effect existing good software), but think "marginal gains". It will also reduce the prospect of link-time error based on ODR (One Definition Rule0.
We should, hopefully, see some build time improvements - mostly through the elimination of repeated large header parsing across translation units (there is a paper from Google correlating post-processed translation unit sizes to build times, but I can't find a reference at the moment - most enlightening).

- Niall

Like (3)

Dislike (0)
Paul Topping says:

August 31, 2021 at 2:31 pm

Thanks for the reply. So far I have two potential advantages of using modules in a project:

* Faster build times.

* Better interface control through hiding of symbols. If I understand this correctly, if I have some public symbols in my module, they still can't be accessed by code outside the module if they aren't placed in the module interface. If I have this right, it would be good to see examples. Are their practical cases where a symbol needs to be public within the module but it is undesirable to expose it outside the module where errant code could make use of it or the symbol's name clashes with one outside the module.

Are their any others? Perhaps avoiding symbol clashes should be its own item. Of course, the code using the module might be developed by someone different than the one that developed the module. Are their cases where packaging some code as a module makes it more useful to others who might want to access the functionality it packages? Are there recommendations for using modules to distribute code? As I understand it, modules is NOT a way to distribute binaries except in very controlled environments. It would be nice to see what the rules are for such controlled environments.

I realize I'm outlining the article that I'm looking for and not necessarily the one you want to write. I'm still surprised no one has written such an article. While I understand the initial focus is on understanding the C++ standard but it would seem answering such questions would be part of the motivation for adding modules to the standard. Perhaps it was but the standards people are too close to the subject to believe it needs to be stated.

Sorry for such a long comment. Thanks for the article.

Like (2)

Dislike (0)
Niall Cooling says:

August 31, 2021 at 2:43 pm

Hi Paul,

I am doing a 2nd part to cover multi-file modules (partitions) which shall cover some of this.

Symbol clashes, not really - this is still driven by namespaces and name-encoding/mangling rules.

I might add a 3rd article discussing these items. However, we are still in the early days of modules and I'm not sure any of us are clear about how build systems, such as CMake, are going to handle modules as components. Ideally, yes, a module should act as a distributable item/artifact; but how this will happen looks like it will be *very* toolchain specific.

- Niall.

Like (4)

Dislike (0)
John Yang says:

January 17, 2022 at 5:45 am

Hi Niall,

Thanks for writing this post. It is really helpful for me to learn "modules" in C++20. However, when I tried to follow your examples with a small twist (i.e. return a std::string instead of void), I ran into a strange linker error.

func.cxx
-----------
export module mod;

import ;

export std::string welcome_msg() {
return "hello world!";
}

main.cpp
------------
import ;
import mod;

int main() {
std::cout << welcome_msg() << std::endl;
return 0;
}

Then I did the following:
g++ -std=c++20 -fmodules-ts -x c++-system-header -c iostream string
g++ -std=c++20 -fmodules-ts -c func.cxx
g++ -std=c++20 -fmodules-ts -c main.cpp
g++ func.o main.o -o hello

The last linker command gave the following error:
ld.exe: main.o:main.cpp:(.text+0x28): multiple definition of `std::__cxx11::basic_string<char, std::char_traits, std::allocator >::_Alloc_hider::~_Alloc_hider()'; func.o:func.cxx:(.text+0x36): first defined here

I don't know how to resolve it. Can you please advise? Thanks you very much.

- John

Like (1)

Dislike (0)
Niall Cooling says:

January 17, 2022 at 11:19 am

Hi John,

You're not including string.
Check ou:
https://godbolt.org/z/joPbd7cT5

Note, on exit from main this seg-faults under GCC.
It runs with no problems using MSVC.

I suspect it's a GCC bug, and will try and investigate further.

Regards,

Niall.

Like (0)

Dislike (0)
Alex says:

June 10, 2022 at 1:13 pm

Hey there. Following this tutorial, I am getting this error when I try to compile the module implementation unit under a Windows environment:

In file included from C:/msys64/mingw64/include/c++/12.1.0/ext/string_conversions.h:41,
from C:/msys64/mingw64/include/c++/12.1.0/bits/basic_string.h:3960,
from C:/msys64/mingw64/include/c++/12.1.0/string:53,
from C:/msys64/mingw64/include/c++/12.1.0/bits/locale_classes.h:40,
from C:/msys64/mingw64/include/c++/12.1.0/bits/ios_base.h:41,
from C:/msys64/mingw64/include/c++/12.1.0/ios:42,
from C:/msys64/mingw64/include/c++/12.1.0/ostream:38,
from C:/msys64/mingw64/include/c++/12.1.0/iostream:39,
from func_impl.cxx:3:
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:124:11: error: 'div_t' has not been declared in '::'
124 | using ::div_t;
| ^~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:125:11: error: 'ldiv_t' has not been declared in '::'
125 | using ::ldiv_t;
| ^~~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:131:11: error: 'atexit' has not been declared in '::'
131 | using ::atexit;
| ^~~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:137:11: error: 'atof' has not been declared in '::'
137 | using ::atof;
| ^~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:138:11: error: 'atoi' has not been declared in '::'
138 | using ::atoi;
| ^~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:139:11: error: 'atol' has not been declared in '::'
139 | using ::atol;
| ^~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:140:11: error: 'bsearch' has not been declared in '::'
140 | using ::bsearch;
| ^~~~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:141:11: error: 'calloc' has not been declared in '::'
141 | using ::calloc;
| ^~~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:142:11: error: 'div' has not been declared in '::'
142 | using ::div;
| ^~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:144:11: error: 'free' has not been declared in '::'
144 | using ::free;
| ^~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:145:11: error: 'getenv' has not been declared in '::'
145 | using ::getenv;
| ^~~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:146:11: error: 'labs' has not been declared in '::'
146 | using ::labs;
| ^~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:147:11: error: 'ldiv' has not been declared in '::'
147 | using ::ldiv;
| ^~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:148:11: error: 'malloc' has not been declared in '::'
148 | using ::malloc;
| ^~~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:150:11: error: 'mblen' has not been declared in '::'
150 | using ::mblen;
| ^~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:151:11: error: 'mbstowcs' has not been declared in '::'
151 | using ::mbstowcs;
| ^~~~~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:152:11: error: 'mbtowc' has not been declared in '::'
152 | using ::mbtowc;
| ^~~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:154:11: error: 'qsort' has not been declared in '::'
154 | using ::qsort;
| ^~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:160:11: error: 'rand' has not been declared in '::'
160 | using ::rand;
| ^~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:161:11: error: 'realloc' has not been declared in '::'
161 | using ::realloc;
| ^~~~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:162:11: error: 'srand' has not been declared in '::'
162 | using ::srand;
| ^~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:163:11: error: 'strtod' has not been declared in '::'
163 | using ::strtod;
| ^~~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:164:11: error: 'strtol' has not been declared in '::'
164 | using ::strtol;
| ^~~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:165:11: error: 'strtoul' has not been declared in '::'
165 | using ::strtoul;
| ^~~~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:168:11: error: 'wcstombs' has not been declared in '::'
168 | using ::wcstombs;
| ^~~~~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:169:11: error: 'wctomb' has not been declared in '::'
169 | using ::wctomb;
| ^~~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:173:10: error: 'ldiv_t' does not name a type; did you mean 'dev_t'?
173 | inline ldiv_t
| ^~~~~~
| dev_t
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:197:11: error: 'lldiv_t' has not been declared in '::'
197 | using ::lldiv_t;
| ^~~~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:207:11: error: 'llabs' has not been declared in '::'
207 | using ::llabs;
| ^~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:209:10: error: 'lldiv_t' does not name a type; did you mean 'dev_t'?
209 | inline lldiv_t
| ^~~~~~~
| dev_t
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:213:11: error: 'lldiv' has not been declared in '::'
213 | using ::lldiv;
| ^~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:224:11: error: 'atoll' has not been declared in '::'
224 | using ::atoll;
| ^~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:225:11: error: 'strtoll' has not been declared in '::'
225 | using ::strtoll;
| ^~~~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:226:11: error: 'strtoull' has not been declared in '::'
226 | using ::strtoull;
| ^~~~~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:228:11: error: 'strtof' has not been declared in '::'
228 | using ::strtof;
| ^~~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:229:11: error: 'strtold' has not been declared in '::'
229 | using ::strtold;
| ^~~~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:237:22: error: 'lldiv_t' has not been declared in '__gnu_cxx'
237 | using ::__gnu_cxx::lldiv_t;
| ^~~~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:241:22: error: 'llabs' has not been declared in '__gnu_cxx'
241 | using ::__gnu_cxx::llabs;
| ^~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:242:22: error: 'div' has not been declared in '__gnu_cxx'
242 | using ::__gnu_cxx::div;
| ^~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:243:22: error: 'lldiv' has not been declared in '__gnu_cxx'
243 | using ::__gnu_cxx::lldiv;
| ^~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:245:22: error: 'atoll' has not been declared in '__gnu_cxx'
245 | using ::__gnu_cxx::atoll;
| ^~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:246:22: error: 'strtof' has not been declared in '__gnu_cxx'
246 | using ::__gnu_cxx::strtof;
| ^~~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:247:22: error: 'strtoll' has not been declared in '__gnu_cxx'
247 | using ::__gnu_cxx::strtoll;
| ^~~~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:248:22: error: 'strtoull' has not been declared in '__gnu_cxx'
248 | using ::__gnu_cxx::strtoull;
| ^~~~~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:249:22: error: 'strtold' has not been declared in '__gnu_cxx'
249 | using ::__gnu_cxx::strtold;
| ^~~~~~~
C:/msys64/mingw64/include/c++/12.1.0/bits/basic_string.h: In function 'int std::__cxx11::stoi(const std::string&, std::size_t*, int)':
C:/msys64/mingw64/include/c++/12.1.0/bits/basic_string.h:3972:47: error: 'strtol' is not a member of 'std'
3972 | { return __gnu_cxx::__stoa(&std::strtol, "stoi", __str.c_str(),
| ^~~~~~
C:/msys64/mingw64/include/c++/12.1.0/bits/basic_string.h: In function 'long int std::__cxx11::stol(const std::string&, std::size_t*, int)':
C:/msys64/mingw64/include/c++/12.1.0/bits/basic_string.h:3977:36: error: 'strtol' is not a member of 'std'
3977 | { return __gnu_cxx::__stoa(&std::strtol, "stol", __str.c_str(),
| ^~~~~~
C:/msys64/mingw64/include/c++/12.1.0/bits/basic_string.h: In function 'long unsigned int std::__cxx11::stoul(const std::string&, std::size_t*, int)':
C:/msys64/mingw64/include/c++/12.1.0/bits/basic_string.h:3982:36: error: 'strtoul' is not a member of 'std'
3982 | { return __gnu_cxx::__stoa(&std::strtoul, "stoul", __str.c_str(),
| ^~~~~~~
C:/msys64/mingw64/include/c++/12.1.0/bits/basic_string.h: In function 'long long int std::__cxx11::stoll(const std::string&, std::size_t*, int)':
C:/msys64/mingw64/include/c++/12.1.0/bits/basic_string.h:3987:36: error: 'strtoll' is not a member of 'std'
3987 | { return __gnu_cxx::__stoa(&std::strtoll, "stoll", __str.c_str(),
| ^~~~~~~
C:/msys64/mingw64/include/c++/12.1.0/bits/basic_string.h: In function 'long long unsigned int std::__cxx11::stoull(const std::string&, std::size_t*, int)':
C:/msys64/mingw64/include/c++/12.1.0/bits/basic_string.h:3992:36: error: 'strtoull' is not a member of 'std'
3992 | { return __gnu_cxx::__stoa(&std::strtoull, "stoull", __str.c_str(),
| ^~~~~~~~
C:/msys64/mingw64/include/c++/12.1.0/bits/basic_string.h: In function 'float std::__cxx11::stof(const std::string&, std::size_t*)':
C:/msys64/mingw64/include/c++/12.1.0/bits/basic_string.h:3998:36: error: 'strtof' is not a member of 'std'
3998 | { return __gnu_cxx::__stoa(&std::strtof, "stof", __str.c_str(), __idx); }
| ^~~~~~
C:/msys64/mingw64/include/c++/12.1.0/bits/basic_string.h: In function 'double std::__cxx11::stod(const std::string&, std::size_t*)':
C:/msys64/mingw64/include/c++/12.1.0/bits/basic_string.h:4002:36: error: 'strtod' is not a member of 'std'
4002 | { return __gnu_cxx::__stoa(&std::strtod, "stod", __str.c_str(), __idx); }
| ^~~~~~
C:/msys64/mingw64/include/c++/12.1.0/bits/basic_string.h: In function 'long double std::__cxx11::stold(const std::string&, std::size_t*)':
C:/msys64/mingw64/include/c++/12.1.0/bits/basic_string.h:4006:36: error: 'strtold' is not a member of 'std'
4006 | { return __gnu_cxx::__stoa(&std::strtold, "stold", __str.c_str(), __idx); }
| ^~~~~~~
In file included from C:/msys64/mingw64/include/c++/12.1.0/ext/string_conversions.h:41,
from C:/msys64/mingw64/include/c++/12.1.0/bits/basic_string.h:3960,
from C:/msys64/mingw64/include/c++/12.1.0/string:53,
from C:/msys64/mingw64/include/c++/12.1.0/bits/locale_classes.h:40,
from C:/msys64/mingw64/include/c++/12.1.0/bits/ios_base.h:41,
from C:/msys64/mingw64/include/c++/12.1.0/ios:42,
from C:/msys64/mingw64/include/c++/12.1.0/ostream:38,
from C:/msys64/mingw64/include/c++/12.1.0/iostream:39:
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:124:11: error: 'div_t' has not been declared in '::'
124 | using ::div_t;
| ^~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:125:11: error: 'ldiv_t' has not been declared in '::'
125 | using ::ldiv_t;
| ^~~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:131:11: error: 'atexit' has not been declared in '::'
131 | using ::atexit;
| ^~~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:137:11: error: 'atof' has not been declared in '::'
137 | using ::atof;
| ^~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:138:11: error: 'atoi' has not been declared in '::'
138 | using ::atoi;
| ^~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:139:11: error: 'atol' has not been declared in '::'
139 | using ::atol;
| ^~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:140:11: error: 'bsearch' has not been declared in '::'
140 | using ::bsearch;
| ^~~~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:141:11: error: 'calloc' has not been declared in '::'
141 | using ::calloc;
| ^~~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:142:11: error: 'div' has not been declared in '::'
142 | using ::div;
| ^~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:144:11: error: 'free' has not been declared in '::'
144 | using ::free;
| ^~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:145:11: error: 'getenv' has not been declared in '::'
145 | using ::getenv;
| ^~~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:146:11: error: 'labs' has not been declared in '::'
146 | using ::labs;
| ^~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:147:11: error: 'ldiv' has not been declared in '::'
147 | using ::ldiv;
| ^~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:148:11: error: 'malloc' has not been declared in '::'
148 | using ::malloc;
| ^~~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:150:11: error: 'mblen' has not been declared in '::'
150 | using ::mblen;
| ^~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:151:11: error: 'mbstowcs' has not been declared in '::'
151 | using ::mbstowcs;
| ^~~~~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:152:11: error: 'mbtowc' has not been declared in '::'
152 | using ::mbtowc;
| ^~~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:154:11: error: 'qsort' has not been declared in '::'
154 | using ::qsort;
| ^~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:160:11: error: 'rand' has not been declared in '::'
160 | using ::rand;
| ^~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:161:11: error: 'realloc' has not been declared in '::'
161 | using ::realloc;
| ^~~~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:162:11: error: 'srand' has not been declared in '::'
162 | using ::srand;
| ^~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:163:11: error: 'strtod' has not been declared in '::'
163 | using ::strtod;
| ^~~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:164:11: error: 'strtol' has not been declared in '::'
164 | using ::strtol;
| ^~~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:165:11: error: 'strtoul' has not been declared in '::'
165 | using ::strtoul;
| ^~~~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:168:11: error: 'wcstombs' has not been declared in '::'
168 | using ::wcstombs;
| ^~~~~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:169:11: error: 'wctomb' has not been declared in '::'
169 | using ::wctomb;
| ^~~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:173:10: error: 'ldiv_t' does not name a type; did you mean 'dev_t'?
173 | inline ldiv_t
| ^~~~~~
| dev_t
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:197:11: error: 'lldiv_t' has not been declared in '::'
197 | using ::lldiv_t;
| ^~~~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:207:11: error: 'llabs' has not been declared in '::'
207 | using ::llabs;
| ^~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:209:10: error: 'lldiv_t' does not name a type; did you mean 'dev_t'?
209 | inline lldiv_t
| ^~~~~~~
| dev_t
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:213:11: error: 'lldiv' has not been declared in '::'
213 | using ::lldiv;
| ^~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:224:11: error: 'atoll' has not been declared in '::'
224 | using ::atoll;
| ^~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:225:11: error: 'strtoll' has not been declared in '::'
225 | using ::strtoll;
| ^~~~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:226:11: error: 'strtoull' has not been declared in '::'
226 | using ::strtoull;
| ^~~~~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:228:11: error: 'strtof' has not been declared in '::'
228 | using ::strtof;
| ^~~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:229:11: error: 'strtold' has not been declared in '::'
229 | using ::strtold;
| ^~~~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:237:22: error: 'lldiv_t' has not been declared in '__gnu_cxx'
237 | using ::__gnu_cxx::lldiv_t;
| ^~~~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:241:22: error: 'llabs' has not been declared in '__gnu_cxx'
241 | using ::__gnu_cxx::llabs;
| ^~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:242:22: error: 'div' has not been declared in '__gnu_cxx'
242 | using ::__gnu_cxx::div;
| ^~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:243:22: error: 'lldiv' has not been declared in '__gnu_cxx'
243 | using ::__gnu_cxx::lldiv;
| ^~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:245:22: error: 'atoll' has not been declared in '__gnu_cxx'
245 | using ::__gnu_cxx::atoll;
| ^~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:246:22: error: 'strtof' has not been declared in '__gnu_cxx'
246 | using ::__gnu_cxx::strtof;
| ^~~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:247:22: error: 'strtoll' has not been declared in '__gnu_cxx'
247 | using ::__gnu_cxx::strtoll;
| ^~~~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:248:22: error: 'strtoull' has not been declared in '__gnu_cxx'
248 | using ::__gnu_cxx::strtoull;
| ^~~~~~~~
C:/msys64/mingw64/include/c++/12.1.0/cstdlib:249:22: error: 'strtold' has not been declared in '__gnu_cxx'
249 | using ::__gnu_cxx::strtold;
| ^~~~~~~
C:/msys64/mingw64/include/c++/12.1.0/bits/basic_string.h: In function 'int std::__cxx11::stoi(const std::string&, std::size_t*, int)':
C:/msys64/mingw64/include/c++/12.1.0/bits/basic_string.h:3972:47: error: 'strtol' is not a member of 'std'
3972 | { return __gnu_cxx::__stoa(&std::strtol, "stoi", __str.c_str(),
| ^~~~~~
C:/msys64/mingw64/include/c++/12.1.0/bits/basic_string.h: In function 'long int std::__cxx11::stol(const std::string&, std::size_t*, int)':
C:/msys64/mingw64/include/c++/12.1.0/bits/basic_string.h:3977:36: error: 'strtol' is not a member of 'std'
3977 | { return __gnu_cxx::__stoa(&std::strtol, "stol", __str.c_str(),
| ^~~~~~
C:/msys64/mingw64/include/c++/12.1.0/bits/basic_string.h: In function 'long unsigned int std::__cxx11::stoul(const std::string&, std::size_t*, int)':
C:/msys64/mingw64/include/c++/12.1.0/bits/basic_string.h:3982:36: error: 'strtoul' is not a member of 'std'
3982 | { return __gnu_cxx::__stoa(&std::strtoul, "stoul", __str.c_str(),
| ^~~~~~~
C:/msys64/mingw64/include/c++/12.1.0/bits/basic_string.h: In function 'long long int std::__cxx11::stoll(const std::string&, std::size_t*, int)':
C:/msys64/mingw64/include/c++/12.1.0/bits/basic_string.h:3987:36: error: 'strtoll' is not a member of 'std'
3987 | { return __gnu_cxx::__stoa(&std::strtoll, "stoll", __str.c_str(),
| ^~~~~~~
C:/msys64/mingw64/include/c++/12.1.0/bits/basic_string.h: In function 'long long unsigned int std::__cxx11::stoull(const std::string&, std::size_t*, int)':
C:/msys64/mingw64/include/c++/12.1.0/bits/basic_string.h:3992:36: error: 'strtoull' is not a member of 'std'
3992 | { return __gnu_cxx::__stoa(&std::strtoull, "stoull", __str.c_str(),
| ^~~~~~~~
C:/msys64/mingw64/include/c++/12.1.0/bits/basic_string.h: In function 'float std::__cxx11::stof(const std::string&, std::size_t*)':
C:/msys64/mingw64/include/c++/12.1.0/bits/basic_string.h:3998:36: error: 'strtof' is not a member of 'std'
3998 | { return __gnu_cxx::__stoa(&std::strtof, "stof", __str.c_str(), __idx); }
| ^~~~~~
C:/msys64/mingw64/include/c++/12.1.0/bits/basic_string.h: In function 'double std::__cxx11::stod(const std::string&, std::size_t*)':
C:/msys64/mingw64/include/c++/12.1.0/bits/basic_string.h:4002:36: error: 'strtod' is not a member of 'std'
4002 | { return __gnu_cxx::__stoa(&std::strtod, "stod", __str.c_str(), __idx); }
| ^~~~~~
C:/msys64/mingw64/include/c++/12.1.0/bits/basic_string.h: In function 'long double std::__cxx11::stold(const std::string&, std::size_t*)':
C:/msys64/mingw64/include/c++/12.1.0/bits/basic_string.h:4006:36: error: 'strtold' is not a member of 'std'
4006 | { return __gnu_cxx::__stoa(&std::strtold, "stold", __str.c_str(), __idx); }
| ^~~~~~~
C:/msys64/mingw64/include/c++/12.1.0/iostream: At global scope:
C:/msys64/mingw64/include/c++/12.1.0/iostream: warning: not writing module 'C:/msys64/mingw64/include/c++/12.1.0/iostream' due to errors

Did you know what it's going on?

Thanks for you time.

Like (2)

Dislike (0)
Niall Cooling says:

June 10, 2022 at 2:59 pm

Hi Alex,

Sorry no, I generally avoid Windows, and if I'm on Windows I'll use WSL2 over MinGW these days for GCC.

Any particular reason you're using MinGW and not WSL2?

Like (0)

Dislike (0)
Alex says:

June 10, 2022 at 4:40 pm

HI Niall, thanks for your response. The reason it's that I am making a cross-compiling automation tool for build C++ projects (https://github.com/Pyzyryab/Zork) on the CMake style, but simpler and lighter, focused in build C++ projects with the new C++20 modules feature. Usually, I work on Unix (mostly Arch) and with LLVM techs. But w'd be fine that the tool could be OS agnostic. Also, it should support at least, Clang, GCC and MSVC, but only Clang it's enabled and it's completly functional (Unix systems only(. After found a lot of troubles compiling projects with Clang that includes legacy headers on Windows, with the MSVC toolchain, I tried to enable the GCC support in the project. But also, isn't compiling due to problems linking legacy headers.

Note that under Unix, Clang compiles fine using GCC as the host-triplet, and it's native support also.

Thanks for your time again!

Like (1)

Dislike (0)
Sterling says:

December 10, 2023 at 10:32 pm

Thanks for the article. Been looking for a while now on a *WORKING* coverage of modules using GCC.

Like (0)

Dislike (0)

C++20 modules with GCC11

Introduction

Pre-C++20 builds

Start with the Why

So What problem are we trying to solve by adding modules?

Other languages

C++20 Module File Structure

Single-file (Complete) Module

Pre-C++20 code

C++20 Module

Separate Interface and Implementation files

Primary Module Interface Unit

Module Implementation Unit

export

Export per function

Export block

Namespace

Export namespace

Exporting Types, etc.

Includes

Summary

Niall Cooling

About Niall Cooling

12 Responses to C++20 modules with GCC11

Leave a ReplyCancel reply

Categories

Archives

C++20 modules with GCC11

Introduction

Pre-C++20 builds

Start with the Why

So What problem are we trying to solve by adding modules?

Other languages

C++20 Module File Structure

Single-file (Complete) Module

Pre-C++20 code

C++20 Module

Separate Interface and Implementation files

Primary Module Interface Unit

Module Implementation Unit

export

Export per function

Export block

Namespace

Export namespace

Exporting Types, etc.

Includes

Summary

Niall Cooling

About Niall Cooling

12 Responses to C++20 modules with GCC11

Leave a ReplyCancel reply

Follow Us

Categories

Archives