How to fix GCC error ‘the lambda has no capture-default’

When encountering a GCC error like this:

error: the lambda has no capture-default

fixing it is usually quite easy. Look for a Lambda function that captures some variable like this

[&myVar] (/* ... */) {/* ... */}

&myVar means “capture myVar by reference”.

In most cases you can just capture all local variables by using a capture default:

[&] (/* ... */) {/* ... */}

In rare cases this will have unintended side-effects as you now are capturing all variables by reference where you might want to capture some by copy – so be sure to check your code.

Note that this error is GCC version-dependent. For me using GCC 7.2 fixed the error.

How to fix GCC error: invalid use of incomplete type ‘class …’

Problem:

You are compiling a C/C++ program using GCC. You get an error message similar to this:

error: invalid use of incomplete type ‘class SomeType’

Solution:

There are multiple possible issues, but in general this error means that GCC can’t find the full declaration of the given class or struct.

The most common issue is that you are missing an #include clause. Find out in which header file the declaration resides, i.e. if the error message mentions class Map, look for something like

class Map {
   // ...
};

Usually the classes reside in header files that are similar to their name, e.g. MyClass might reside in a header file that is called MyClass.h, MyClass.hpp or MyClass.hxx, so be sure to look for those files first. Note that you might also be looking for a type from a library. Often the best approach is to google C++ <insert the missing type here> to find out where it might be located.

Another possible reason is that you have your #include clause after the line where the error occurs. If this is the case, ensure that all required types are included before they are used.

For other reasons, see StackOverflow, e.g. this post

How to resolve fatal error: bytecode stream generated with LTO version … instead of the expected …

Problem:

When compiling a program or library with GCC, you get an error message similar to this:

fatal error: bytecode stream generated with LTO version 5.1 instead of the expected 5.2

Solution:

This error basically means that you’ve got some binary build results (mostly object files) which are incompatible with other binary build results, but you’re trying to link them together. The LTO part just means that the incompatibility is due to you having link-time optimization enabled – but you don’t need to worry about that, you can just treat it like any other incompatibility.

In almost all cases, there is a very simple reason for the error: You have built your project with an older GCC version, then updated GCC and re-compiled (partially, as not all files have been changed) later. In this case, there is a simple solution: Just clean your build and re-build from scratch.

If you use make (or CMake), this is usually as simple as

make clean # Remove old, incompatible files
make # Rebuild

For other buildsystems, lookup how to clean your build accordingly – or just delete your build or dist directory if that doesn’t cause any unintended side effects.

In some very rare cases, an issue in the build system configuration causes the software to be built with two different compilers. If you think that might be the case (i.e. if the cleaning process does not help), I suggest trying to look at the verbose output of your build system — however, keep in mind that it’s more likely that you’re trying to link a stray object file that has been built with an older version of the compiler.

If you’re happy with just fixing the symptom while ignoring the possibility of hard-to-debug incompatibilities, you can just omit the -flto flag in the build system config. This hides the LTO incompatibility as it disables the link-time optimizer altogether, but even if no new error codes are shown, this approach is generally not recommended.