-isystem leads to code wrapped in extern "C"

[Pedro Kiefer]

The toolchain fails to build c++ files correctly when using -isystem, as it treats all headers as being wrapped in `extern "C"`. Other versions of gcc (x86, linaro arm-linux, etc) handles this use case. It seems to be solved on upstreams versions of gcc, but not on this arm-none-eabi version.

I've tested it with 6-2016-q4-major, and 6-2017-q1-update.

related threads:
https://gcc.gnu.org/ml/gcc-patches/2012-06/msg01159.html
https://gcc.gnu.org/ml/gcc-help/2016-02/msg00002.html

[Tejas Belagod (belagod-tejas)]

Hi Pedro,

What is the symptom you're observing?

Thanks,
Tejas.

[Torsten Robitzki (torstenrobitzki)]

One symptom for example is, that the compiler generates errors, when it hits a template declaration: "error: template with C linkage"

[Tejas Belagod (belagod-tejas)]

Hi,

I will need a test case to reproduce the issue.

THanks,
Tejas.

[Torsten Robitzki (torstenrobitzki)]

Have a file t.cpp:

    #include "t.h"

    int main()
    {}

given t.h is in a subdirectory called test/ and looks like this:

    template < class T >
    void foo();

Compiling t.cpp with:

$ arm-none-eabi-g++ t.cpp -isystem test
In file included from t.cpp:1:0:
test/t.h:2:1: error: template with C linkage
 template < class T >
 ^~~~~~~~

See attached the process output.

Kind regards,

Torsten

[Gergely Budai (gbudai76)]

This is a real pain since it makes impossible to include C++ library header files with -isystem. They must be included as standard includes (-I) which makes compilation very noisy.

[Gergely Budai (gbudai76)]

The reported behavior is still the same with 7-2017-q4-major. Are there any plans to build the binaries with NO_IMPLICIT_EXTERN_C ?

See: https://gcc.gnu.org/ml/gcc-help/2011-09/msg00157.html

[Jim Lloyd (etajim)]

I'm using the g++ 7.2 arm-none-eabi compiler shipped with the Xilinx SDK 2018.1 and am impacted by this issue.

[Torsten Robitzki (torstenrobitzki)]

As a workaround, you can include a header and include the needed C++ headers from within an `extern "C++"` block. For example:

extern "C++" {
# include "assert_hash/assert_hash.hpp"
}

[Jim Lloyd (etajim)]

@torstenrobitzki I don't think that is a workaround we can use. We have code that extensively uses C++ headers, and we are using CMake plus the [Hunter package management system](https://github.com/ruslo/hunter) to manage our dependencies on external C++ packages such as Boost.

[Torsten Robitzki (torstenrobitzki)]

And the problem still persists with 7.3.1

[Matt Ihnen (matt-ihnen)]

Any news on this... not sure how something like this could be open for a whole year and still not be fixed.

[Gergely Budai (gbudai76)]

@belagod-tejas: Any plans to change this behavior in the near future in the official binary packages?

[Bart Staal (bart.staal)]

This makes it difficult to use this toolchain in combination with Bazel. It's uses -isystem to pass include directories to the compiler and there seems no easy way to change this.

[Gergely Budai (gbudai76)]

One possible solution that worked for me is to manually recompile the binaries from the sources with NO_IMPLICIT_EXTERN_C defined.

Steps needed:
- Download and extract the source package
- extract the gcc source package (src/gcc.tar.bz2) somewhere
- Modify the sources that NO_IMPLICIT_EXTERN_C is defined. (I am not sure where the right place is for this definition, so I defined it in gcc/gcc/config/arm/arm.h)
- Repack and replace the gcc source package (src/gcc.tar.bz2)
- Compile the binaries as described in How-to-build-toolchain.pdf

If someone discovers an easier/better way to do this, please don't hesitate to describe it.

[Andreas Pokorny (andreas-pokorny)]

I think the best way to go forward is to just ignore arm and start our own ppa.
This is known for years and no reaction see: https://bugs.launchpad.net/gcc-arm-embedded/+bug/1585322

[Torsten Robitzki (torstenrobitzki)]

I think ARM is just doing what every company is doing: react to the loudest complains first. Maybe we should ask other colleges, who are pestered by this bug to fill duplicates or to at least subscribe to this bug, to raise the "bug heat" :-)

[Andreas Pokorny (andreas-pokorny)]

I filed this issue also at the ubuntu package - which is probably better maintained:
https://bugs.launchpad.net/ubuntu/+source/gcc-arm-none-eabi/+bug/1789395

[Andreas Pokorny (andreas-pokorny)]

upcoming gcc releases - I suspect gcc 9, will have that setting inverted and machine configs need to explicitly activate that behavior with SYSTEM_IMPLICIT_EXTERN_C.

[Thomas Preud'homme (thomas-preudhomme)]

Indeed Andreas. I've tested with the testcase provided in comment #4 (https://bugs.launchpad.net/gcc-arm-embedded/+bug/1698539/comments/4) and it works. It has been changed by revision 262437 on 5th of July. I'm marking the bug as Fix committed as a result (yes it will not be fixed in the next GNU Arm Embedded Toolchain release but the fix is committed and will be released as soon as we release a toolchain based of GCC 9).

Best regards.