727141 - Build busted in mfbt on inbound

Status: RESOLVED FIXED

(Core :: MFBT, defect)

Description

[Richard Newman [:rnewman]]

Assertions.cpp
In file included from /Users/rnewman/moz/android/android-ndk-r6/platforms/android-8/arch-arm/usr/include/stdio.h:56,
                 from /Users/rnewman/moz/android/android-ndk-r6/sources/cxx-stl/stlport/stlport/stl/_cstdio.h:35,
                 from /Users/rnewman/moz/android/android-ndk-r6/sources/cxx-stl/stlport/stlport/cstdio:29,
                 from /Users/rnewman/moz/hg/mozilla-inbound/mfbt/Assertions.cpp:45:
/Users/rnewman/moz/android/android-ndk-r6/platforms/android-8/arch-arm/usr/include/sys/types.h:121: error: 'uint32_t' does not name a type
/Users/rnewman/moz/android/android-ndk-r6/platforms/android-8/arch-arm/usr/include/sys/types.h:122: error: 'uint16_t' does not name a type
/Users/rnewman/moz/android/android-ndk-r6/platforms/android-8/arch-arm/usr/include/sys/types.h:123: error: 'uint8_t' does not name a type
/Users/rnewman/moz/android/android-ndk-r6/platforms/android-8/arch-arm/usr/include/sys/types.h:124: error: 'uint64_t' does not name a type
In file included from /Users/rnewman/moz/android/android-ndk-r6/platforms/android-8/arch-arm/usr/include/asm/siginfo.h:16,
                 from /Users/rnewman/moz/android/android-ndk-r6/platforms/android-8/arch-arm/usr/include/signal.h:39,
                 from /Users/rnewman/moz/hg/mozilla-inbound/mfbt/Assertions.cpp:48:
/Users/rnewman/moz/android/android-ndk-r6/platforms/android-8/arch-arm/usr/include/asm-generic/siginfo.h:58: warning: ISO C++ forbids zero-size array '_pad'

In the directory  /Users/rnewman/moz/hg/mozilla-inbound/objdir-droid/mfbt
The following command failed to execute properly:
/usr/local/bin/ccache /Users/rnewman/moz/android/android-ndk-r6/toolchains/arm-linux-androideabi-4.4.3/prebuilt/darwin-x86/bin/arm-linux-androideabi-g++ -o Assertions.o -c -fvisibility=hidden -DIMPL_MFBT -DOSTYPE="Linux" -DOSARCH=Linux -I/Users/rnewman/moz/hg/mozilla-inbound/mfbt -I. -I../dist/include -I../dist/include/nsprpub -I/Users/rnewman/moz/hg/mozilla-inbound/objdir-droid/dist/include/nspr -I/Users/rnewman/moz/hg/mozilla-inbound/objdir-droid/dist/include/nss -fPIC -I/Users/rnewman/moz/android/android-ndk-r6/platforms/android-8/arch-arm/usr/include -I/Users/rnewman/moz/android/android-ndk-r6/sources/cxx-stl/stlport/stlport -fno-rtti -pedantic -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-invalid-offsetof -Wno-variadic-macros -Werror=return-type -Wno-long-long -mandroid -I/Users/rnewman/moz/android/android-ndk-r6/platforms/android-8/arch-arm/usr/include -fno-short-enums -fno-exceptions -march=armv7-a -mthumb -mfpu=vfp -mfloat-abi=softfp -fno-exceptions -fno-strict-aliasing -std=gnu++0x -ffunction-sections -fdata-sections -pipe -DNDEBUG -DTRIMMED -g -Os -freorder-blocks -fno-reorder-functions -fomit-frame-pointer -I/Users/rnewman/moz/android/android-ndk-r6/platforms/android-8/arch-arm/usr/include -I/Users/rnewman/moz/android/android-ndk-r6/sources/cxx-stl/stlport/stlport -DMOZILLA_CLIENT -include ../mozilla-config.h -MD -MF .deps/Assertions.pp /Users/rnewman/moz/hg/mozilla-inbound/mfbt/Assertions.cpp
make[5]: *** [Assertions.o] Error 1
make[4]: *** [libs_tier_base] Error 2
make[3]: *** [tier_base] Error 2
make[2]: *** [default] Error 2
make[1]: *** [realbuild] Error 2
make: *** [build] Error 2

Related to Bug 717540?

Comment 1

[Jeff Walden [:Waldo]]

Attachment: Assertions.i from a failing build

The corresponding Assertions.i is informative: what happens is . being mfbt/ means that the StdInt.h in there is searched for headers.  And it happens it's searched before the standard include location is.  (This is the case even for <>-style includes, not just for ""-style includes, which seems insane to me, but it's what we have right now.)  So when we #include "mozilla/StdInt.h", that sub-#includes <stdint.h>, which case-insensitively hits "mozilla/StdInt.h" again, which include-guards its way into nothingness, so the integral types aren't defined properly.

It was suggested on IRC to make the path be <../include/stdint.h> to work around this.  That depends on the standard include directory being (leaf-)named "include", which seems a little dodgy.  <sys/> seems like a plausible good guess for a standard-include subdirectory present everywhere, so I'm trying out <sys/../stdint.h> on try right now.  If that builds, I think we can run with that.

https://tbpl.mozilla.org/?tree=Try&rev=9a1471c30863

Comment 2

[Rafael Ávila de Espíndola (:espindola) (not reading bugmail)]

> So when we #include
> "mozilla/StdInt.h", that sub-#includes <stdint.h>, which case-insensitively
> hits "mozilla/StdInt.h" again, which include-guards its way into
> nothingness, so the integral types aren't defined properly.

Can we change the -I flags so that one always has to use mozilla/StdInt.h to get our header instead of the system one? Having a common prefix (mozilla/) used on #includes is probably a good thing.

Comment 3

[Jeff Walden [:Waldo]]

Well, you have to use mozilla/StdInt.h to get it now.  It's only if you're in a directory with a file named stdint.h (case-insensitively) that you run into issues.  There are two directories in the tree which hit this, and I think only mfbt/ has issues that result from it.

I do think it would be good and proper if -I. were after the system include location in build commands.  That seems like a larger change than is desirable here, and probably requires roping in more people to be sure everything's fine with it.

Comment 4

[Jeff Walden [:Waldo]]

Try was green enough that it looks like every platform is happy with that change, so I pushed it to inbound, with rs=khuey over IRC:

https://hg.mozilla.org/integration/mozilla-inbound/rev/e5df0f4321ad

Comment 5

[Marco Bonardo [:mak]]

https://hg.mozilla.org/mozilla-central/rev/e5df0f4321ad