May 2017 - CRUX-ARM - lists.crux-arm.nu

Compilation firefox-53.0.2 ends with an error
by Milan Buska 31 May '17

31 May '17

Hi. Compile firefox-53.0.2. /devel/firefox/work/src/firefox-53.0.2/obj-armv7l-unknown-linux-gnueabihf/_virtualenv/bin/python /devel/firefox/work/src/firefox-53.0.2/config/expandlibs_gen.py -o libipc_glue.a.desc BackgroundChildImpl.o BackgroundParentImpl.o FileDescriptorSetChild.o FileDescriptorSetParent.o GeckoChildProcessHost.o URIUtils.o Unified_cpp_ipc_glue0.o Unified_cpp_ipc_glue1.o make[5]: Leaving directory '/devel/firefox/work/src/firefox-53.0.2/obj-armv7l-unknown-linux-gnueabihf/ipc/glue' libdocshell_base.a.desc rm -f libdocshell_base.a /devel/firefox/work/src/firefox-53.0.2/obj-armv7l-unknown-linux-gnueabihf/_virtualenv/bin/python /devel/firefox/work/src/firefox-53.0.2/config/expandlibs_gen.py -o libdocshell_base.a.desc Unified_cpp_docshell_base0.o make[5]: Leaving directory '/devel/firefox/work/src/firefox-53.0.2/obj-armv7l-unknown-linux-gnueabihf/docshell/base' make[4]: Leaving directory '/devel/firefox/work/src/firefox-53.0.2/obj-armv7l-unknown-linux-gnueabihf' make[3]: *** [/devel/firefox/work/src/firefox-53.0.2/config/recurse.mk:33: compile] Error 2 make[3]: Leaving directory '/devel/firefox/work/src/firefox-53.0.2/obj-armv7l-unknown-linux-gnueabihf' make[2]: *** [/devel/firefox/work/src/firefox-53.0.2/config/rules.mk:522: default] Error 2 make[2]: Leaving directory '/devel/firefox/work/src/firefox-53.0.2/obj-armv7l-unknown-linux-gnueabihf' make[1]: *** [/devel/firefox/work/src/firefox-53.0.2/client.mk:419: realbuild] Error 2 make[1]: Leaving directory '/devel/firefox/work/src/firefox-53.0.2' make: *** [client.mk:170: build] Error 2 Where can be a mistake ? Regards -- --------------------------------------------------- Remember, no question is too stupid and no problem too small--We've all been beginners

3 11

Re: [crux-arm] crux 3.3 on aarch64
by Victor Martinez 23 May '17

23 May '17

* Peter Johansson (rossolis8240(a)telia.com) wrote: > Hello Victor! > Hey Peter, > > > > > How did you do that? From cross compilation or deploying the generic aarch63 image? > > It was not so hard, from zero it did take me about 10days (never done any ports before) > I used pi64, a very naked 64bit rootsystem that are based on debian aarch64. > > 1. Booted it on a external usb-disk. (that need separate 5v power) Also added a fan to cool the cpu. > 2. Downloaded build-sysroot and gcc tools from linaro > 3. Compiled gcc 6.3.0 on pc to be used on the target system and with some essential files like "init". > 4. Removed the debian based /etc + debian files and placed crux 3.3 version there instead. > 5. With the compiler in place the "real" work began, to build everything from zero. > Step by step new programs were built, for example linux-utils,pkg-utils > We work in a different way. We start from scratch at cross compiling level. We genererate a crossrootfs and then we deploy it to the powerfull machine where we rebuild core ports collection natively with generic CFLAGS in two stages (two passes). After this, we have a rootfs to deploy to any compat device and let users optimize their devices or run a generic build. All these steps are a bit explained here [1] and [2]. > > > Got X11 to work yesterday with fbturbo. > > > Been very stable all the time. > A note, crux 3.3 default xorg-libpixman are buggy on aarch64, X11 did freeze are a short while. > The latest pixman (35.1 git) will solve that. > I should make some tests and provide an overlay for aarch64 then. Thank you for the info. > Now everything work just fine. > > > > Added this to the Pkgfile to be able to make some packages (aarch64 unknown) > > > > > > sed 's/abacus)/aarch64)/g' -i config.sub > > > sed 's/abacus-unknown/aarch64-linux/g' -i config.sub > > > > > > ./configure --prefix=/usr --build=aarch64-linux-gnu > > > > > Thank you very much for the information provided. I've faced the build arch problem and > > some specific ports related to aarch64 too. > > I did discover there is need of a third line to (some x11 packages need it) > Add sed 's/a29k/aarch64/g' > > With them I successfully built the whole system. > > Made a small patch-skript "aap" (cat /root/aa-mod.txt >> Pkfile; mcedit Pkgfile) > Moved the lines in place with mcedit > All done in seconds :) > Taking note to read about the a29k detail. > > We have ready a generic release for aarch64 [1] and another optimized one for the pine64 [2]. > > In both cases we try to keep near CRUX and specally with everything related to the toolchain. > > Currently we provide gcc 6.3.0 and binutils 2.27 (as CRUX and CRUX-ARM 32b). > > > We don't plan to move far from CRUX in any port version, only for exceptions when we need > > to create a port overlay for specific device needs. > Good idea. Me myself used 7.1.0 because it has (i think) best aarch64 (hard to find)support. > It can be overlayed too, but this will put us far from CRUX and this isn't the idea. May be keep the same version and look for patches or just wait. CRUX-ARM aarch64 is still under development because these reasons (not only toolchain components aren't ready yet for aarch64, there are lot of software, like you told about X11 stuf, not ready/pulished yet). > > Actually we don't have an rpi3 to provide an optimized release nor test the generic one > > on it. Good to know that someone else got CRUX-ARM working on this amazing device. > It is a amazing small board, it perform very well and very cheap to. > > > The xorg fbturbo driver should work just fine, but without providing acceleration. I think, > > at least, it could be great to make a port for /opt/VC and firmware (I had something done > > for the raspberrypi 1 for video playing if I remember right). > > In my system I built mesa3D v17 and libdrm freedreno, however the freedreno failed to start. > It seem like the 3D performance are quite good to, did see on the internet some got quite demanding > 3D games to run, how good I dont know, it will be interesting to find out. > That sounds promising really (currently I'm using the pine64 as a headless server, but I plan to deploy X11 and make some test with the TV soon if I find some spare time). > Working now on getting mplayer to work, it compiles(with some help) but like with many of the other programs, aarch64 not yet > fully supported. In mplayer the float/dsp hardware are not used right. > Too much work ahead for aarch64 architecture... but time to time, there are lot of people working in this "new" architecture. Soon we'll start seeing software ready to be built cleanly on these devices. > Regards > Peter > Regards, [1] https://crux-arm.nu/Documentation/HowDoWeWork [2] https://crux-arm.nu/Documentation/HowToContribute --- Victor Martinez Learning bit by bit | http://vjml.es

1 0

crux 3.3 on aarch64
by Peter Johansson 22 May '17

22 May '17

Hello! In the last few days I have completed a crux-3.3 port on aarch64 (Raspberry Pi 3) Built all packages on it, core, xorg, gcc-7.1.0, binutils-2.28 Got X11 to work yesterday with fbturbo. Been very stable all the time. Added this to the Pkgfile to be able to make some packages (aarch64 unknown) sed 's/abacus)/aarch64)/g' -i config.sub sed 's/abacus-unknown/aarch64-linux/g' -i config.sub ./configure --prefix=/usr --build=aarch64-linux-gnu Regards Peter Johansson

2 1