June 2018 - CRUX-ARM - lists.crux-arm.nu

I'm basically done with Crux ARM64b on OdroidC2
by Thierry Moreau 05 Jun '18

05 Jun '18

Hi Victor, I'm basically done with Crux Arm64b on Odroid C2. Overall, the Odroid C2 builds packages at circa 2.75 faster than reported times for other arm native builds (I'm not a fan of benchmarks, so not a firm statement against a specific alternative). For opt/xpdf, I changed a dependency from qt4 to qt5, the former being a bit outdated. The build opt/qt5 required a change from -reduce-relocations to -no-reduce-relocations. The build opt/ghostscript required a setting -DPNG_ARM_NEON_OPT=0 in CPPFLAGS because the arm neon optimisation source code requires an assembler source file that is not compliant to arm64 (the error message was less instructional than my root cause explanation). (I wrongly reported that ghostscript has been build.) I forgot to send you my odroidc2-arm64 port collection, which is an adaptation of pine64-arm port collection. Since my project goals are more towards removing packages, protocol support, and other software functions that are not necessary for some specific security-intensive applications, I am not inclined to keep up to date with package revisions. This is the meaning of "I'm basically done." Still, I might make a revision to my document for a section on building Crux packages, but it's not too high on my list of priorities. I wish to thank you and the Crux Arm team for this marvelous Linux distribution preparation methodology. Regards, - Thierry

1 0

build chromium crux-arm
by Milan Buška 05 Jun '18

05 Jun '18

Hello, I have just finished compiling the port of chromium successfully. Pleasant is that there is no need to make any modifications to Pkgfile. As you can see, the crux 3.4/opt/chromium port is fully compatible with crux-arm64 Regards -- ---------------------------------------------------------------------------- Remember, no question is too stupid and no problem too small--We've all been beginners

2 1

Fwd: Definition of release in Pkgfile
by Milan Buška 03 Jun '18

03 Jun '18

---------- Forwarded message ---------- From: Milan Buška <milan.buska(a)gmail.com> Date: 2018-06-02 16:46 GMT+02:00 Subject: Re: [crux-arm] Definition of release in Pkgfile To: Fredrik Rinnestam <fredrik(a)rinnestam.se> Hello. 2018-06-02 15:03 GMT+02:00 Fredrik Rinnestam <fredrik(a)rinnestam.se>: > On Sat, Jun 02, 2018 at 01:14:18PM +0200, Milan Buška wrote: >> Hello. >> >> How do I define the release value in Pkgfile. >> >> Example: >> I have the port xyz - release=1 >> I use four patches in the xyz port - release=4 >> >> I understand it correctly. >> >> Regards >> >> Milan > > $release is just the version of the Pkgfile itself. If you change the > port in some way like changing build-options or adding patches without > the $version chaning - then you should increment the $release. This is > to differentiate the port. > > > -- > > Fredrik Rinnestam > _______________________________________________ > crux-arm mailing list > crux-arm(a)crux-arm.nu > https://crux-arm.nu/mailman/listinfo/crux-arm crux firefox port => version=60.0.1 release=1 crux-arm64 firefox port - I have to use four patches for build crux-arm64 firefox port => version=60.0.1 release=4 Thank you for the lesson -- ---------------------------------------------------------------------------- Remember, no question is too stupid and no problem too small--We've all been beginners -- ---------------------------------------------------------------------------- Remember, no question is too stupid and no problem too small--We've all been beginners

2 2

Definition of release in Pkgfile
by Milan Buška 02 Jun '18

02 Jun '18

Hello. How do I define the release value in Pkgfile. Example: I have the port xyz - release=1 I use four patches in the xyz port - release=4 I understand it correctly. Regards Milan -- ---------------------------------------------------------------------------- Remember, no question is too stupid and no problem too small--We've all been beginners

2 1

xorg packages in Crux Arm64: great successes until attempting to build a web browser
by Thierry Moreau 02 Jun '18

02 Jun '18

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

4 7