"error: template with C linkage" within nested include

Bug #1710838 reported by Torsten Robitzki
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
GNU Arm Embedded Toolchain
New
Undecided
Unassigned

Bug Description

I have a situation, where a cpp-file includes a header and that header includes <utility>. This results in arm-none-eabi-g++ complaining about a „template with C linkage“ when it sees the first template declaration in stl_relops.h, which is included by <utility>. When I directly include <utility> from the cpp-file, this error is not reported. The „template with C linkage“ is even reported, when the included header contains nothing (but include guards).

For me, the problem is easily reproducible by the short attached output of the preprocessor:

$ arm-none-eabi-g++ t.cpp -x c++ -std=c++14 -fmax-errors=1
In file included from /usr/local/gcc-arm-none-eabi-6-2017-q1-update/arm-none-eabi/include/c++/6.3.1/utility:69:0,
                 from /Users/todi/bluetoe/bluetoe/options.hpp:4,
                 from /Users/todi/blueswd_firmware/source/firmware/bootloader.cpp:1:
/usr/local/gcc-arm-none-eabi-6-2017-q1-update/arm-none-eabi/include/c++/6.3.1/bits/stl_relops.h:85:5: error: template with C linkage
     template <class _Tp>
     ^~~~~~~~

If line 6 and 10 are removed or if the nesting information in both lines are shortened by one, the error is not reported.

I would expect the attached code to compile without error (and to fail at the linking stage).

The compiler spec:

$ arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-arm-none-eabi-6-2017-q1-update/bin/../lib/gcc/arm-none-eabi/6.3.1/lto-wrapper
Target: arm-none-eabi
Configured with: /tmp/jenkins-GCC-6-build_build-toolchain-mac-143_20170216_1487268977/src/gcc/configure --target=arm-none-eabi --prefix=/tmp/jenkins-GCC-6-build_build-toolchain-mac-143_20170216_1487268977/install-native --libexecdir=/tmp/jenkins-GCC-6-build_build-toolchain-mac-143_20170216_1487268977/install-native/lib --infodir=/tmp/jenkins-GCC-6-build_build-toolchain-mac-143_20170216_1487268977/install-native/share/doc/gcc-arm-none-eabi/info --mandir=/tmp/jenkins-GCC-6-build_build-toolchain-mac-143_20170216_1487268977/install-native/share/doc/gcc-arm-none-eabi/man --htmldir=/tmp/jenkins-GCC-6-build_build-toolchain-mac-143_20170216_1487268977/install-native/share/doc/gcc-arm-none-eabi/html --pdfdir=/tmp/jenkins-GCC-6-build_build-toolchain-mac-143_20170216_1487268977/install-native/share/doc/gcc-arm-none-eabi/pdf --enable-languages=c,c++ --enable-plugins --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-newlib --with-headers=yes --with-python-dir=share/gcc-arm-none-eabi --with-sysroot=/tmp/jenkins-GCC-6-build_build-toolchain-mac-143_20170216_1487268977/install-native/arm-none-eabi --build=x86_64-apple-darwin10 --host=x86_64-apple-darwin10 --with-gmp=/tmp/jenkins-GCC-6-build_build-toolchain-mac-143_20170216_1487268977/build-native/host-libs/usr --with-mpfr=/tmp/jenkins-GCC-6-build_build-toolchain-mac-143_20170216_1487268977/build-native/host-libs/usr --with-mpc=/tmp/jenkins-GCC-6-build_build-toolchain-mac-143_20170216_1487268977/build-native/host-libs/usr --with-isl=/tmp/jenkins-GCC-6-build_build-toolchain-mac-143_20170216_1487268977/build-native/host-libs/usr --with-libelf=/tmp/jenkins-GCC-6-build_build-toolchain-mac-143_20170216_1487268977/build-native/host-libs/usr --with-host-libstdcxx='-static-libgcc -Wl,-lstdc++ -lm' --with-pkgversion='GNU Tools for ARM Embedded Processors 6-2017-q1-update' --with-multilib-list=rmprofile
Thread model: single
gcc version 6.3.1 20170215 (release) [ARM/embedded-6-branch revision 245512] (GNU Tools for ARM Embedded Processors 6-2017-q1-update)

Running on macOS Sierra 10.12.6

Revision history for this message
Torsten Robitzki (torstenrobitzki) wrote :
Revision history for this message
Torsten Robitzki (torstenrobitzki) wrote :

I see the same error when using 4_8-2014q2 or gcc-arm-none-eabi-6-2017-q2-update

Revision history for this message
Torsten Robitzki (torstenrobitzki) wrote :

And the overall example can be reduced to:

# 1 "t.hpp" 1 3 4

template < class T >
int foo();

Revision history for this message
Torsten Robitzki (torstenrobitzki) wrote :

Now, I realized that this problem goes away, when I do not use "-isystem" switch to pass the include path for the included header to the compiler (but the normal -I switch).

Revision history for this message
Ashish Singh (assingh1) wrote :

hi robitzki,
can you please tell me the way to change -isystem to -I. I am facing same issue while compiling gtest packages using gcc-arm-none-eabi-8-2019-q3-update

Revision history for this message
Sebastian Delling (sdelling) wrote :

hi,

when working with CMake I used -DCMAKE_NO_SYSTEM_FROM_IMPORTED=ON to not have imports set as -isystem and then compilations finished successfully.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.