607975 - allow building fennec-android on win32

Status: RESOLVED DUPLICATE of bug 1169873

(Firefox Build System :: General, defect)

Description

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: fix android build on win32

This small patch allows us to build fennec-android on win32, using the win32 crystax NDK + cygwin host compiler.  Using MSVC as the host compiler is impossible; too much of our build system assumes that the host and target compilers are the same type of compiler (e.g. take the same type of options), which isn't the case between msvc and gcc.

Ted, the rules.mk change just makes us use a @file for the args instead of passing them all on the command line; without this, libxul can't link since the command line ends up being way too long for cygwin.

Here's a sample mozconfig; building with pymake has problems, so normal make has to be used.  The build needs to be done from the normal mozilla-build (msys) environment, not from cygwin.  Also, to stop path warning span, CYGWIN=nodosfilewarning should be set in the environment.

# This is the same as /c/mozilla-build/moztools, except it has
# the libIDL and libglib from
# http://ftp.mozilla.org/pub/mozilla.org/mozilla/source/wintools.zip
# We can probably get rid of this if we rebuild the current libIDL
# to not depend on MSVC-specific runtime math functions.
MOZ_TOOLS=/c/mozilla-build/moztools-mingw

HOST_CC=/c/cygwin/bin/i686-w64-mingw32-gcc-4.5.1.exe
HOST_CXX=/c/cygwin/bin/i686-w64-mingw32-gcc-4.5.1.exe
HOST_CPP=/c/cygwin/bin/i686-w64-mingw32-cpp.exe
HOST_LD=/c/cygwin/bin/i686-w64-mingw32-gcc-4.5.1.exe
HOST_AR=/c/cygwin/bin/i686-w64-mingw32-ar.exe
HOST_RANLIB=/c/cygwin/bin/i686-w64-mingw32-ranlib.exe

# Path to android ndk/sdk/tools/etc., msys style.  DOS paths
# are also likely to work, but untested.
ac_add_options --with-android-ndk="/c/proj/android-sdk-windows/android-ndk-r4-crystax"
ac_add_options --with-android-sdk="/c/proj/android-sdk-windows/platforms/android-8"
ac_add_options --with-android-tools="/c/proj/android-sdk-windows/tools"
ac_add_options --with-android-toolchain="/c/proj/android-sdk-windows/android-ndk-r4-crystax/build/prebuilt/windows/arm-eabi-4.4.0"

# Need an explicit path to java
ac_add_options --with-java-bin-path="/c/proj/jdk1.6.0_20/bin"

# configure.in gets confused
ac_add_options --disable-libIDLtest

#ac_add_options --enable-debug
ac_add_options --enable-optimize
ac_add_options --enable-debug-symbols
ac_add_options --disable-tests

# android options
ac_add_options --enable-application=mobile
ac_add_options --target=arm-android-eabi
ac_add_options --with-endian=little

# crash reporter has lots of confusion about host vs. target
# in the build; I tried fixing some of it and gave up, it's not
# important
ac_add_options --disable-crashreporter

# The cygwin-based cross compiler will generate dependencies
# that have /cygwin/c/ style paths in them, which will never be
# found by make; this will result in every target always being
# rebuilt.  This isn't ideal, and could be fixed by either postprocessing
# the .pp files, or adding an option to pymake to get it to understand
# cygwin paths in dependencies.
ac_add_options --disable-auto-deps

Comment 1

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Oh -- you'll need cygwin installed, with the mingw 4.5.1 compiler.  Additionally, you'll need to copy all the DLLs from c:\cygwin\bin into a new directory, like C:\cygwin\bindll and add that to your msys path (can't just add the bin dir, as that will cause a bunch of conflicts as make will try to execute cygwin versions of standard tools)

Comment 2

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: part 1, allow android build under win32

fixed a few things; "--with-android-toolchain" is no longer required.

Comment 3

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: Set NO_TLS in jemalloc

This patch is required to get a build that doesn't hang in TLS access in jemalloc, at least in an opt build.  mwu says he's seen this in other instances as well (with the mega-libxul patch), but I could only reproduce it when building under win32, not under linux.  Didn't look into it in any more detail.

With this build, I have done a successful debug build.  An opt build completes, but the resulting build has issues on the device -- things are alive, but it doesn't repaint properly, and events don't seem to be handled correctly.  Whatever's causing it is likely the same as what requires this jemalloc patch.

Attaching this patch here, though we don't want to check it in (though we may actually want to, since it will improve jemalloc perf a tiny bit, and the TLS usage doesn't help us since we have just one arena anyway).

Comment 4

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: part 2, fix auto dep generation

this fixes auto gcc dep generation by post-processing the pp files.  much better than using mkdepend etc.

Comment 5

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: part 3, fix libvpx build

libvpx builds a host tool to extract some data from .o files; that tool depends on elf.h.  This is practically impossible to install from any package and still use the msys/mingw gcc host compiler that other things depend on (there's a cygwin package, but that's not available to mingw).  Instead, I just copy the relevant elf.h bits in (they're BSD licensed) and rename the header files, and #include those if we're building with a mingw compiler.

Comment 6

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: part 4, fix freetype build

freetype got a sub-configure which has a pretty broken attempt to find the host C compiler when cross-compiling.  This only really seems to come into play when a .def file needs to be generated, so this should work fine; we don't care about the .sym file with gcc.

Comment 7

[(not currently active) Ted Mielczarek]

Comment on attachment 487137 [details] [diff] [review]
part 1, allow android build under win32


>diff --git a/config/rules.mk b/config/rules.mk
>--- a/config/rules.mk
>+++ b/config/rules.mk
>@@ -1355,7 +1355,19 @@ endif
> 	@rm -f $(MOZILLA_PROBE_LIBS)
> 
> else # ! DTRACE_LIB_DEPENDENT
>+ifdef GNU_CC
>+ifneq (,$(SUB_SHLOBJS))
>+	@rm -f $(SHARED_LIBRARY_NAME).response
>+	@for file in $(SUB_SHLOBJS); do \
>+		echo "$${file}" >> $(SHARED_LIBRARY_NAME).response ; \
>+	done
>+	$(MKSHLIB) $(SHLIB_LDSTARTFILE) $(OBJS) $(DTRACE_PROBE_OBJ) $(LOBJS) @$(SHARED_LIBRARY_NAME).response $(RESFILE) $(LDFLAGS) $(EXTRA_DSO_LDOPTS) $(call EXPAND_FAKELIBS,$(OS_LIBS) $(EXTRA_LIBS)) $(DEF_FILE) $(SHLIB_LDENDFILE)
>+else
> 	$(MKSHLIB) $(SHLIB_LDSTARTFILE) $(OBJS) $(DTRACE_PROBE_OBJ) $(LOBJS) $(SUB_SHLOBJS) $(RESFILE) $(LDFLAGS) $(EXTRA_DSO_LDOPTS) $(call EXPAND_FAKELIBS,$(OS_LIBS) $(EXTRA_LIBS)) $(DEF_FILE) $(SHLIB_LDENDFILE)
>+endif
>+else
>+	$(MKSHLIB) $(SHLIB_LDSTARTFILE) $(OBJS) $(DTRACE_PROBE_OBJ) $(LOBJS) $(SUB_SHLOBJS) $(RESFILE) $(LDFLAGS) $(EXTRA_DSO_LDOPTS) $(call EXPAND_FAKELIBS,$(OS_LIBS) $(EXTRA_LIBS)) $(DEF_FILE) $(SHLIB_LDENDFILE)
>+endif # GNU_CC

Why is this hunk necessary?

>diff --git a/configure.in b/configure.in
>--- a/configure.in
>+++ b/configure.in
>@@ -283,7 +283,14 @@ if test "$target" = "arm-android-eabi" ;
>     fi
> 
>     if test -z "$android_toolchain" ; then
>-        android_toolchain="$android_ndk"/build/prebuilt/`uname -s | tr "[[:upper:]]" "[[:lower:]]"`-x86/arm-eabi-4.4.0
>+        case "$host" in
>+        *-cygwin*|*-mingw*)
>+          android_toolchain="$android_ndk"/build/prebuilt/windows/arm-eabi-4.4.0
>+          ;;
>+        *)
>+          android_toolchain="$android_ndk"/build/prebuilt/`uname -s | tr "[[:upper:]]" "[[:lower:]]"`-x86/arm-eabi-4.4.0

Feels like maybe we should just explicitly set out all the supported host platforms here and ditch the uname|tr bit.

>@@ -1178,7 +1185,7 @@ if test -n "$MAKE"; then
>   fi
> fi
> 
>-case "$host_os" in
>+case "$host" in
> cygwin*|mingw*|mks*|msvc*)

Uh, this shouldn't work.  $host will be like i686-unknown-mingw32.

Comment 8

[(not currently active) Ted Mielczarek]

Comment on attachment 490203 [details] [diff] [review]
part 3, fix libvpx build

I assume we'll want to upstream this somehow to avoid your changes getting blown away the next time we update libvpx?

Also I'm not sure I'm really the right reviewer for this. Run it past one of the media guys?

Comment 9

[(not currently active) Ted Mielczarek]

Comment on attachment 490252 [details] [diff] [review]
part 4, fix freetype build

I really don't feel qualified to review this, I don't know anything about how freetype's build works. We're going to have to upstream this if you want to take it, do you think they'd take this patch?

Comment 10

[Brad Lassey [:blassey] (use needinfo?)]

(In reply to comment #9)
> Comment on attachment 490252 [details] [diff] [review]
> part 4, fix freetype build
> 
> I really don't feel qualified to review this, I don't know anything about how
> freetype's build works. We're going to have to upstream this if you want to
> take it, do you think they'd take this patch?

as I understand it, there are two problems here. First, freetype's configure isn't finding the mingw toolchain its looking for. Second, it doesn't actually need a host toolchain to cross compile with a gcc toolchain.

Vlad,did you figure out why freetype couldn't find your host tools? I'm a little concerned that in the future we may need them and this would be broken.

Comment 11

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Comment on attachment 490203 [details] [diff] [review]
part 3, fix libvpx build

Only thing that really needs to be upstreamed here is the obj_int_extract.c change, and even that we could just maintain as a local patch because it's only hit in such an odd build env (android cross-build on win32).  The other files are just additions (BSD-licensed).

Comment 12

[Timothy B. Terriberry (:derf)]

Comment on attachment 490203 [details] [diff] [review]
part 3, fix libvpx build

These changes should also be included as a separate patch that is applied by update.sh, like media/libvpx/solaris.patch. This allows updating the library via that script, as described in https://wiki.mozilla.org/WebM/Updating_libvpx
r+ with that addition.

I do encourage you to submit the change upstream, however. It is an oddball configuration, but there's no conceptual reason that the host should have ELF support.

Comment 13

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

(In reply to comment #10)
> (In reply to comment #9)
> > Comment on attachment 490252 [details] [diff] [review]
> > part 4, fix freetype build
> > 
> > I really don't feel qualified to review this, I don't know anything about how
> > freetype's build works. We're going to have to upstream this if you want to
> > take it, do you think they'd take this patch?
> 
> as I understand it, there are two problems here. First, freetype's configure
> isn't finding the mingw toolchain its looking for. Second, it doesn't actually
> need a host toolchain to cross compile with a gcc toolchain.
> 
> Vlad,did you figure out why freetype couldn't find your host tools? I'm a
> little concerned that in the future we may need them and this would be broken.

Well, it's only looking for 'gcc' or 'cc', and in this case we need it to use the mingw gcc.  The ${build} platform is cygwin as well, and I don't see any way to pass in a compiler.  The patch is correct for us, since HOST_CC will always be set right whether we're cross compiling or not, but isn't right for upstream..

Comment 14

[Martijn Wargers (dead)]

Attachment: my .mozconfig file

I tried to get this working on my Windows machine. I had to change some stuff, because Vlad's .mozconfig and patch are outdated.

But I'm currently stuck here:
checking for /c/android-tegra/android-ndk-r5/toolchains/arm-linux-androideabi-4.
4.3/prebuilt/windows/bin/arm-eabi-gcc... /c/android-tegra/android-ndk-r5/toolcha
ins/arm-linux-androideabi-4.4.3/prebuilt/windows/bin/arm-eabi-gcc
checking for gcc... /c/android-tegra/android-ndk-r5/toolchains/arm-linux-android
eabi-4.4.3/prebuilt/windows/bin/arm-eabi-gcc
checking whether the C compiler (/c/android-tegra/android-ndk-r5/toolchains/arm-
linux-androideabi-4.4.3/prebuilt/windows/bin/arm-eabi-gcc -mandroid -I/c/android
-tegra/android-ndk-r5/platforms/android-5/arch-arm/usr/include -fno-short-enums
-fno-exceptions  -mandroid -L/c/android-tegra/android-ndk-r5/platforms/android-5
/arch-arm/usr/lib -L/c/android-tegra/android-ndk-r5/sources/cxx-stl/gnu-libstdc+
+/libs/armeabi-v7a -Wl,-rpath-link=/c/android-tegra/android-ndk-r5/platforms/and
roid-5/arch-arm/usr/lib --sysroot=/c/android-tegra/android-ndk-r5/platforms/andr
oid-5/arch-arm -llog -Wl,--allow-shlib-undefined ) works... no
configure: error: installation or configuration problem: C compiler cannot creat
e executables.
*** Fix above errors and then restart with               "make -f client.mk buil
d"
make[2]: *** [configure] Error 1
make[2]: Leaving directory `/c/mozilla-build/android'
make[1]: *** [obj-i686-pc-mingw32/Makefile] Error 2
make[1]: Leaving directory `/c/mozilla-build/android'
make: *** [build] Error 2

I don't see any arm-eabi-gcc file at /c/android-tegra/android-ndk-r5/toolchains/arm-linux-android , so I guess that is the problem?
eabi-4.4.3/prebuilt/windows/bin/arm-eabi-gcc

Comment 15

[Martijn Wargers (dead)]

Attachment: Vlad's patches applied to current tree

Comment 16

[Martijn Wargers (dead)]

I guess I need to build the arm-eabi-gcc files myself from the Crystax r4 NDK or something?

Comment 17

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.