4.6-11.11 seems to misdetect some files as system header and implicit extern "C"

[Bernhard Rosenkraenzer]

Trying to build Android ICS with 4.6-11.11 results in a number of errors, e.g.:

frameworks/base/include/utils/StrongPointer.h:32:1: error: template with C linkage

Initially, I suspected some header has an unclosed extern "C" { somewhere, but after looking at the preprocessor output, the problem seems to be that gcc marks certain files as system header and implicitly extern "C" when they're clearly non-system C++ headers (flags 3 and 4 set in the # lines in preprocessor output).

Problematic bits in the attached sample include
# 1 "frameworks/base/include/private/media/AudioTrackShared.h" 1 3 4
# 23 "frameworks/base/include/private/media/AudioTrackShared.h" 3 4
# 1 "frameworks/base/include/utils/threads.h" 1 3 4
# 22 "frameworks/base/include/utils/threads.h" 3 4

Is there any reason why the compiler is marking those "3 4"?
It's certainly unexpected and there doesn't seem to be an easy workaround.

[Bernhard Rosenkraenzer (berolinux)]

FWIW the call that produces this is

/opt/android-toolchain-11.11/bin/arm-eabi-g++ -I dalvik/libnativehelper/include/nativehelper -I external/skia/include/core -I external/skia/include/core -I ./frameworks/base/include/media/stagefright/openmax -I external/icu4c/common -I external/expat/lib -I system/media/audio_effects/include -I frameworks/base/media/libmedia -I out/target/product/panda/obj/SHARED_LIBRARIES/libmedia_intermediates -I out/target/product/panda/obj/STATIC_LIBRARIES/libwebcore_intermediates -I dalvik/libnativehelper/include/nativehelper -isystem system/core/include -isystem hardware/libhardware/include -isystem hardware/libhardware_legacy/include -isystem hardware/ril/include -isystem dalvik/libnativehelper/include -isystem frameworks/base/include -isystem frameworks/base/opengl/include -isystem frameworks/base/native/include -isystem external/skia/include -isystem out/target/product/panda/obj/include -isystem bionic/libc/arch-arm/include -isystem bionic/libc/include -isystem bionic/libstdc++/include -isystem bionic/libc/kernel/common -isystem bionic/libc/kernel/arch-arm -isystem bionic/libm/include -isystem bionic/libm/include/arm -isystem bionic/libthread_db/include -c -fno-exceptions -Wno-multichar -msoft-float -fpic -ffunction-sections -fdata-sections -funwind-tables -fstack-protector -Wa,--noexecstack -Werror=format-security -fno-short-enums -march=armv7-a -mfloat-abi=softfp -mfpu=neon -include system/core/include/arch/linux-arm/AndroidConfig.h -I system/core/include/arch/linux-arm/ -Wno-psabi -mthumb-interwork -DANDROID -fmessage-length=0 -W -Wall -Wno-unused -Winit-self -Wpointer-arith -Werror=return-type -Werror=non-virtual-dtor -Werror=address -Werror=sequence-point -DNDEBUG -g -Wstrict-aliasing=2 -fgcse-after-reload -frerun-cse-after-loop -frename-registers -DNDEBUG -UDEBUG -fvisibility-inlines-hidden -DANDROID -fmessage-length=0 -W -Wall -Wno-unused -Winit-self -Wpointer-arith -Wsign-promo -Werror=return-type -Werror=non-virtual-dtor -Werror=address -Werror=sequence-point -DNDEBUG -UDEBUG -mthumb -Os -fomit-frame-pointer -fno-strict-aliasing -fno-rtti -E -MD -o out/target/product/panda/obj/SHARED_LIBRARIES/libmedia_intermediates/AudioTrack.i frameworks/base/media/libmedia/AudioTrack.cpp

So chances are it's detected as a system header because of the "-isystem frameworks/base/include" bit (which seems ultimately bogus, looks like someone abused -isystem to append something to the include path).
So the only remaining question is why gcc is marking it "4" - AFAIK gcc is supposed to treat all system headers as extern "C"...

Anyway, looks like the best fix is to get rid of the -isystem abuse in ICS

[Ulrich Weigand (uweigand)]

>So the only remaining question is why gcc is marking it "4" - AFAIK gcc is supposed to treat all system headers as extern "C"...

This depends on the target system the compiler is built for. In "linux" builds, the compiler assumes that system headers are properly C++ aware, and does not do any "magic" extern "C" handling. However, in "eabi" builds, the compiler assumes that system headers may be old and not C++ aware, and therefore automatically adds an implicit extern "C" around all system headers.

From the above, it would appear your compiler is built for an eabi target.

[Michael Hope (michaelh1)]

Closing as wont fix: the command line sets these as system header files and the -eabi configuration forces these to extern "C".

[Milosz Wasilewski (mwasilew)]

At the moment 4.7 seems to work fine and we're moving to 4.8. Closing as won't fix.