1169873 - (fennecwindows) [meta] Make Firefox for Android build on Microsoft Windows

Status: RESOLVED FIXED

(Firefox Build System :: Android Studio and Gradle Integration, task)

Description

[Nick Alexander :nalexander [he/him]]

Right now, we don't /support/ building Fennec on Windows.  I know of no reason that Fennec /does not/ build on Windows; and I see no strong reason why it /could not/ build on Windows.  The only vague suspicion I have is that mobile/android assumes the underlying system can create symlinks; and that we're not careful to escape paths correctly.  Neither of these are show stoppers -- they just require work to track down and address.

This ticket tracks comments, requests, and fixes to the tree.

Comment 1

[Nick Alexander :nalexander [he/him]]

For the record, this probably gets better if and when we build with Gradle.  (Facebook's buck (and Twitter's pants) do not support Windows at all, to the best of my knowledge.)

Comment 2

[Mike Hommey [:glandium]]

Off the top of my head, at the very least:
- elfhack and szip don't compile on windows, but they don't on mac either iirc
- the build system makes many assumptions that the toolchain used for HOST_SOURCES is kind of the same (same family, so to speak) as the one used for SOURCES. That is, you'll have a hard time if you try to use MSVC for HOST_SOURCES and gcc/clang for SOURCES.

Comment 3

[Jan Henning [:JanH]]

Attachment: example log of trying to build Fennec on Windows

Okay, just for the fun of it I've actually tried building Fennec on Windows 7, but as expected I didn't get very far.
Because of c#2, I've tried both with the MSVC shell (start-shell-msvc2015.bat), and the normal shell with Clang added to the PATH, but at least at the stage where my build is currently breaking, this doesn't seem to make any difference.

I've been using this mozconfig:
# Build Firefox for Android:
ac_add_options --enable-application=mobile/android
ac_add_options --target=arm-linux-androideabi

# With the following Android SDK and NDK:
ac_add_options --with-android-sdk="D:/Android/android-sdk/platforms/android-22"
ac_add_options --with-android-ndk="D:/Android/android-ndk-r10e"
ac_add_options --with-android-toolchain="D:/Android/android-ndk-r10e/toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64"

I've also set up my JAVA_HOME so that it points (via a filesystem junction) to a directory without spaces in its path.

So far, I've run into the following problems:
The Android build tools are searched in the wrong directory. For some reason, the location of the mozilla-build\msys directory gets prepended to the path.
So e.g. instead of D:\Android\android-sdk\build-tools\22.0.1, it's searching under D:\mozilla-build\msys\Android\android-sdk\build-tools\22.0.1

After adding a temporary filesystem junction, the next problem is that it can't find dx. This is because on Windows dx is a batch file (dx.bat), but for some reason configure is only looking for dx and dx.exe, which again I temporarily fixed by creating a hardlink from dx to dx.bat.

Next, it switches to configuring/compiling freetype2, where path handling on Windows seems broken, because when accessing the makefile, it strips the colon from the volume letter and tries accessing "/d/mozilla-source/mozilla-central/modules/freetype2/Makefile", which naturally fails. If I create a junction to mozilla-source at "D:\d", it finds the makefile (at "D:\d\mozilla-source\mozilla-central\modules\freetype2\Makefile"), but it's still broken.
Amongst other things, it then tries to access the C compiler with this path: "D:\Android\android-ndk-r10e\toolchains\arm-linux-androideabi-4.9\prebuilt\WINDOWS-X86_64' '--DISABLE-SHARED' '--WITH-PIC=YES' '--WITH-ZLIB=YES' '--WITHOUT-BZIP2' '--WITH-PNG=YES' '--WITHOUT-HARFBUZZ' '--CACHE-FILE=D", and then tries accessing some other files where it has stripped even the slashes from the file path (according to Process Monitor e.g. "D:\usr\local\bin\D:mozilla-buildmsysAndroidandroid-sdkplatformsandroid-22"), apart from the fact that there is no "usr\local\bin" on Windows.

Because my knowledge of build scripts and the like is nearly zero, I have to declare defeat at this stage and hope for help from somebody else :-)

Comment 4

[Nick Alexander :nalexander [he/him]]

bsheila727: what's the ask here?  I have nothing to contribute at this time.

Comment 5

[Nick Alexander :nalexander [he/him]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=7f71f2876d48

Comment 6

[Nick Alexander :nalexander [he/him]]

Attachment: MozReview Request: Bug 1169873 - Part 1: WIP on using Path instances in Java JAR declarations.

I'm just pushing this out to capture my thoughts.  There are lots of
path incompatibilities running java and javac on Windows.  I think the
best approach is to use @argument files with javac; that decouples the
paths produced for javac from the paths that Make uses.  In turn,
that's much easier to achieve if we use Path instances in the
recursive make backend.

This patch does this for Java JAR files.  To complete this approach,
we need to lift some Makefile.in variables (JAVAFILES,
ANDROID_EXTRA_JARS) into moz.build, so that we can modify the
@argument files for classes.dex easily.  That's getting into a decent
amount of work, and I think it's better to put that energy into just
building with Gradle.

Review commit: https://reviewboard.mozilla.org/r/32293/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/32293/

Comment 7

[Alex Johnson (:alex_johnson)]

Would the new Windows 10 bash help with this?

Comment 8

[Nick Alexander :nalexander [he/him]]

(In reply to Alex Johnson (:alex_johnson) from comment #7)
> Would the new Windows 10 bash help with this?

I don't really know.  Probably, since the Windows issues are mostly path related; and since the output (an APK) isn't a Linux or Windows binary.

Comment 9

[Makoto Kato [:m_kato]]

(In reply to Nick Alexander :nalexander from comment #8)
> (In reply to Alex Johnson (:alex_johnson) from comment #7)
> > Would the new Windows 10 bash help with this?
> 
> I don't really know.  Probably, since the Windows issues are mostly path
> related; and since the output (an APK) isn't a Linux or Windows binary.

Creator Update or later can run Java VM, so javac and some tools work well.  But it doesn't still support 32-bit ELF.  So I filed bug 1370119 for build-tools.

Comment 12

[Cathy Lu [:calu]]

Is this fine to close, doesn't look like there is active work on this.

Comment 13

[Makoto Kato [:m_kato]]

Although this is experimental, it is ready to build GeckoView on Windows without any patches now. Bug 1621844 requires when using NDK r21. But since we are moved to NDK r23, that bug is unnecessary.

Comment 14

[Nick Alexander :nalexander [he/him]]

Agreed.

Comment 15

[Kagami Rosylight [:saschanaz] (they/them) (OOO until 2024-10-06)]

Should we remove this warning in that case?

            if host.raw_os == "mingw32":
                log.warning(
                    "Building Firefox for Android on Windows is not fully "
                    "supported. See https://bugzilla.mozilla.org/show_bug.cgi?"
                    "id=1169873 for details."
                )

Comment 16

[Nick Alexander :nalexander [he/him]]

(In reply to Kagami [:saschanaz] (they/them) from comment #15)

Should we remove this warning in that case?

            if host.raw_os == "mingw32":
                log.warning(
                    "Building Firefox for Android on Windows is not fully "
                    "supported. See https://bugzilla.mozilla.org/show_bug.cgi?"
                    "id=1169873 for details."
                )

Sure. Flag :m_kato for review, they understand the details best at this point.