Open Bug 1169873 (fennecwindows) Opened 4 years ago Updated 3 days ago
[meta] Make Firefox for Android build on Microsoft Windows
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.
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.)
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.
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 :-)
bsheila727: what's the ask here? I have nothing to contribute at this time.
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/
Would the new Windows 10 bash help with this?
(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.
(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.
You need to log in before you can comment on or make changes to this bug.