Hi,
as you may have noticed I installed Crux Arm 64 bits on the Odroid C2
hardware.
Since I reported on the milestone of GUI-less installation, I had the
pleasure to realize that the default "fbdev" X11 driver allows xorg
applications built almost trivially. I build openbox, xterm, gvim,
geeqie, ghostscript. Then I made a minimal xorg.conf file, and those
applications worked nicey as soon as I soft-linked ~/.xinitrc to
/usr/bin/openbox.
"Almost trivially" must be understood in the context of the Crux
philosophy and the fact that the target architecture is not officially
supported by the Crux Arm volunteer efforts. I did not need to
troubleshoot any source code, just some minor build process details, for
the above X11 packages.
The fbdev X11 driver does not provide the GUI acceleration from the ARM
Mali GPU present on this Amlogic SOC target. Not a design goal for me.
Thus, I am quite well served by the Crux Arm offerings. Thanks.
The heavyweight X11 application is the web browser (any of them is a
monster). This is problematic in this native build environment with 2GB
CPU memory and a slow (and potentially unreliable?) MicroSD "mass storage".
Firefox build quits with a cc1-process-being-killed message, with meager
troubleshooting application. Filed a bug report on Mozilla, did not
attract attention.
I am frightened by the 400MB tarball size for Chromium (and I would like
to avoid Chromium as it would not fit some project policies).
Opera port (from contrib) does not download automatically, so building
for ARM64 might be challenging.
The other two candidates are midori and surf (both from contrib) and are
looking less monstruous.
Surf is based on webkitgtk (from opt) and a few ports from contrib which
were built almost trivially. The web browser complexity seems mostly
within the webkitgtk package, but fortunately the webkit package (and
its gtk variant) is backed by an active open source community (there is
a section on building for ARM devices on the basic instruction pages for
package build).
My current difficulty is with webkitgtk port build, using cmake with
which I am not familiar. Some DerivedSources seem to be missing (ending
as an #include file not found) but I noticed (more fundamentally) that a
MacroAssembler<target>.h was selected for X86 while the ARM64 version is
present (while ARM64 switches/defines do appear somewhere in a cmake
cache file).
I leave midori aside for now.
Any comment, any suggestion?
Since the X11 installation went well for smaller size applications, I
guess the overall approach is okay and the steep learning curve for
building a web browser in a foreign architecture is unavoidable.
If we step back a moment, is there any way to procure an X.11 web
browser -- even one with 5 to 10 years lag in functionality -- in binary
form or otherwise as a first proof-of-concept milestone?
Regards,
- Thierry
