Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Build busted in mfbt on inbound

RESOLVED FIXED in mozilla13

Status

()

Core
MFBT
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: rnewman, Assigned: Waldo)

Tracking

unspecified
mozilla13
ARM
Android
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
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?
Created attachment 597108 [details]
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
Assignee: nobody → jwalden+bmo
Status: NEW → ASSIGNED
Blocks: 717540
> 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.
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.
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
Target Milestone: --- → mozilla13
https://hg.mozilla.org/mozilla-central/rev/e5df0f4321ad
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.