xorg packages in Crux Arm64: great successes until attempting to build a web browser
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
* Thierry Moreau (thierry.moreau@connotech.com) wrote:
Hi,
Hello Thierry,
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.
There are ports overlays for opt and xorg collections ready for arm64. I've tested them on the pine64 and all is working right with fbdev. I was able to run Mali on the cubieboard but I didn't mess with 64b stuff. Arm64 arch was tested the first time in CRUX-ARM 64b 3.3 and it will be officially supported on the next release (3.4) which we are working on currently. The base is ready from the toolchain to the ports overlays as you can see repositories and branches in the development section.
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".
This is a shared problem on embedded devices. I started connecting an external harddrive to make builds and finished using a nfs share over a NAS.
Firefox build quits with a cc1-process-being-killed message, with meager troubleshooting application. Filed a bug report on Mozilla, did not attract attention.
That's not a bug, it's an error about not enoght memory to build right. You need a big swap file (not sure if 8GB are enoght, mine is 16GB) to build these packages (firefox, chromium, QT,...) I've tested firefox on the pine64 and it's working right too
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?
Make a big swap file and firefox will build without problems, It'll take much time, probably around 30h without CPU throtling due to temperature problems. Good heatsink and fan help on big builds.
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?
I don't like to play with packages because you need all linked ones. This is hard to manage and not the aim of a source based distro.
Regards,
- Thierry _______________________________________________ crux-arm mailing list crux-arm@crux-arm.nu https://crux-arm.nu/mailman/listinfo/crux-arm
Regards, --- Victor Martinez Learning bit by bit | http://vjml.es
On 29/05/18 04:40 AM, Victor Martinez wrote:
Hello Thierry,
Thanks for the quick and relevant reply. I should install NFS-based swap space (and a CPU cooling arrangement).
There are ports overlays for opt and xorg collections ready for arm64. I've tested them on the pine64 and all is working right with fbdev. I was able to run Mali on the cubieboard but I didn't mess with 64b stuff.
By any chance, would you have any hint about building the opt/webkitgtk port. I had success for every dependencies, but failed for webkitgtk itself on a missing JavaScriptCore/JSContextRef.h file which should have been made at work/src/build/DerivedSources/ForwardingHeaders/JavaScriptCore/JSContextRef.h .
Arm64 arch was tested the first time in CRUX-ARM 64b 3.3 and it will be officially supported on the next release (3.4) which we are working on currently. The base is ready from the toolchain to the ports overlays as you can see repositories and branches in the development section.
I don't like to play with packages because you need all linked ones. This is hard to manage and not the aim of a source based distro.
Well understood. The small changes I found necessary are all recorded in cloned git repositories. If I was more comfortable with git concepts, I would readily volunteer to share my findings. E.g. I had to aling the source=(...) entry in a Pkgfile to match the contents of .md5sum in a port in opt-arm; I committed this with git, and now I must fight with git log and/or git rev-list options to remind me which port it was. Patience! Regards, - Thierry
On Tue, 29 May 2018 12:03:43 +0000 Thierry Moreau <thierry.moreau@connotech.com> wrote:
On 29/05/18 04:40 AM, Victor Martinez wrote:
Hello Thierry,
Thanks for the quick and relevant reply. I should install NFS-based swap space (and a CPU cooling arrangement).
There are ports overlays for opt and xorg collections ready for arm64. I've tested them on the pine64 and all is working right with fbdev. I was able to run Mali on the cubieboard but I didn't mess with 64b stuff.
By any chance, would you have any hint about building the opt/webkitgtk port. I had success for every dependencies, but failed for webkitgtk itself on a missing JavaScriptCore/JSContextRef.h file which should have been made at work/src/build/DerivedSources/ForwardingHeaders/JavaScriptCore/JSContextRef.h .
I hit this when building single threaded. I have a patch for it in my 'forks' repo: https://stygian.me/crux/ports-forks/webkitgtk/fix_js_forwarding_headers.patc... I am also attaching a copy of it. Cheers, - John
On 29/05/18 01:58 PM, John Vogel wrote:
On Tue, 29 May 2018 12:03:43 +0000 Thierry Moreau <thierry.moreau@connotech.com> wrote:
By any chance, would you have any hint about building the opt/webkitgtk port. I had success for every dependencies, but failed for webkitgtk itself on a missing JavaScriptCore/JSContextRef.h file which should have been made at work/src/build/DerivedSources/ForwardingHeaders/JavaScriptCore/JSContextRef.h .
I hit this when building single threaded. I have a patch for it in my 'forks' repo:
https://stygian.me/crux/ports-forks/webkitgtk/fix_js_forwarding_headers.patc...
Thanks a lot, this worked as intended. - Thierry
* Thierry Moreau (thierry.moreau@connotech.com) wrote:
On 29/05/18 04:40 AM, Victor Martinez wrote:
Hello Thierry,
Thanks for the quick and relevant reply. I should install NFS-based swap space (and a CPU cooling arrangement).
There are ports overlays for opt and xorg collections ready for arm64. I've tested them on the pine64 and all is working right with fbdev. I was able to run Mali on the cubieboard but I didn't mess with 64b stuff.
By any chance, would you have any hint about building the opt/webkitgtk port. I had success for every dependencies, but failed for webkitgtk itself on a missing JavaScriptCore/JSContextRef.h file which should have been made at work/src/build/DerivedSources/ForwardingHeaders/JavaScriptCore/JSContextRef.h .
No sorry Thierry. Only firefox and chromium experience here (only firefox for 64b arch).
Arm64 arch was tested the first time in CRUX-ARM 64b 3.3 and it will be officially supported on the next release (3.4) which we are working on currently. The base is ready from the toolchain to the ports overlays as you can see repositories and branches in the development section.
I don't like to play with packages because you need all linked ones. This is hard to manage and not the aim of a source based distro.
Well understood. The small changes I found necessary are all recorded in cloned git repositories. If I was more comfortable with git concepts, I would readily volunteer to share my findings.
E.g. I had to aling the source=(...) entry in a Pkgfile to match the contents of .md5sum in a port in opt-arm; I committed this with git, and now I must fight with git log and/or git rev-list options to remind me which port it was. Patience!
Feel free to share them and I'll check, test and update our tree.
Regards,
- Thierry
Regards, --- Victor Martinez Learning bit by bit | http://vjml.es
Hi Victor, first of all, thanks for the suggestion to build large packages with some swap file arrangements. I used NFS-based swap file with a size of 10GB and everything went well. On 30/05/18 03:41 PM, Victor Martinez wrote:
* Thierry Moreau (thierry.moreau@connotech.com) wrote:
By any chance, would you have any hint about building the opt/webkitgtk port. I had success for every dependencies, but failed for webkitgtk itself on a missing JavaScriptCore/JSContextRef.h file which should have been made at work/src/build/DerivedSources/ForwardingHeaders/JavaScriptCore/JSContextRef.h .
No sorry Thierry. Only firefox and chromium experience here (only firefox for 64b arch).
I got a reply with a very specific and relevant patch file which I included in the local port collection adaptations. (included in the files I am sending in a separate message)
Well understood. The small changes I found necessary are all recorded in cloned git repositories. If I was more comfortable with git concepts, I would readily volunteer to share my findings.
E.g. I had to aling the source=(...) entry in a Pkgfile to match the contents of .md5sum in a port in opt-arm; I committed this with git, and now I must fight with git log and/or git rev-list options to remind me which port it was. Patience!
Feel free to share them and I'll check, test and update our tree.
I am sending you those in an off-list message. Regard, - Thierry
Hello. 2018-05-29 4:04 GMT+02:00 Thierry Moreau <thierry.moreau@connotech.com>:
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.
This is an idea but can be a solution for speeding up rendering. see https://github.com/archlinuxarm/PKGBUILDs/tree/master/alarm/xf86-video-fbtur... see https://github.com/tnmeyer/xf86-video-fbturbo
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 _______________________________________________ crux-arm mailing list crux-arm@crux-arm.nu https://crux-arm.nu/mailman/listinfo/crux-arm
Regards Milan -- ---------------------------------------------------------------------------- Remember, no question is too stupid and no problem too small--We've all been beginners
participants (4)
-
John Vogel -
Milan Buška -
Thierry Moreau -
Victor Martinez