You are not logged in.
Other than alanyih's (rather successful) attempt for arm, which seems to be stuck at
serious issue.
Floating point exception
from 10 months ago, I couldn't find any others who've tried to get Slitaz on arm.
But why aim so high for armhf immediately?
Unfortunately, alanyih while strong technically, tends to leave some rather cryptic notes at times. And I couldn't find if they've left notes on how they built their initial bootable ISO.
So does anyone have any idea on how to start (trying to build Slitaz for armel)?
Thanks!
Offline
cross-compile VS. native compile
1. cross-compile:
slitaz-armhf-cross-toolchain
slitaz-arm-toolchain-armhf-20120630.tar.bz2
Target: arm-slitaz-linux-gnueabi
--with-sysroot=/cross/arm/sysroot --with-arch=armv6 --with-fpu=vfp --with-float=hard
http://forum.slitaz.org/topic/chroot#post-18038
Chrooting to: /home/slitaz/cooking/arm/chroot
[..]
3.
root@slitaz:/# arm-slitaz-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-slitaz-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/cross/arm/tools/lib/gcc/arm-slitaz-linux-gnueabi/4.6.3/lto-wrapper
Target: arm-slitaz-linux-gnueabi
Configured with: ../gcc-4.6.3/configure --prefix=/cross/arm/tools --libexec=/cross/arm/tools/lib --target=arm-slitaz-linux-gnueabi --enable-shared --enable-c99 --enable-long-long --enable-__cxa_atexit --with-system-zlib --enable-plugin --disable-multilib --disable-libssp --disable-checking --disable-werror --with-pkgversion=SliTaz --with-bugurl=https://bugs.slitaz.org/ --with-sysroot=/cross/arm/sysroot --with-arch=armv6 --with-fpu=vfp --with-float=hard --enable-languages=c,c++
Thread model: posix
gcc version 4.6.3 (SliTaz)
2. native compile:
http://forum.slitaz.org/topic/chroot/page/3#post-26286
Compiling with qemu-arm-static chroot
Target: arm-slitaz-linux-gnueabi
--build=arm-slitaz-linux-gnueabi --host=arm-slitaz-linux-gnueabi
[..]
3.
root@slitaz:/# gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-slitaz-linux-gnueabi/4.6.3/lto-wrapper
Target: arm-slitaz-linux-gnueabi
Configured with: /home/slitaz/wok/gcc/source/gcc-4.6.3/configure --prefix=/usr --libexecdir=/usr/lib --enable-languages=c,c++ --enable-shared --enable-c99 --enable-long-long --enable-__cxa_atexit --with-system-zlib --enable-plugin --disable-multilib --disable-libssp --disable-checking --disable-werror --disable-bootstrap --enable-clocale=gnu --enable-lto --enable-threads=posix --with-arch=armv6 --with-fpu=vfp --with-float=hard --with-pkgversion=SliTaz --build=arm-slitaz-linux-gnueabi --host=arm-slitaz-linux-gnueabi
Thread model: posix
gcc version 4.6.3 (SliTaz)
Offline
Hi! And thanks for answering!
It would be better if you explained a bit more and shared your perspective and interpretation. Even if you write in your native language and then we can paste it into Google Translate or something. 
1a. But doesn't chroot assume you have a <i>sh</i> (or <i>busybox</i>) binary in /home/slitaz/cooking/arm/chroot/bin already? (Or what do I need to cook with it after this step to create a base system for armel? I'm trying to run it on a Raspberry Pi so I don't need a kernel (so NOT "linux" but which package is next?).)
1b. This implies the same binaries /cross/arm/tools/bin/arm-slitaz-linux-gnueabi-* can target both armhf and armv6 (armel)??
1c. How does arm-slitaz-linux-gnueabi-* compare to other cross compilers such as arm-bcm2708-linux-gnueabi from
https://github.com/raspberrypi/tools/tree/master/arm-bcm2708
2. I prefer this if possible.
2a. Same as above: Don't I need an armel (not armhf) <i>/bin/busybox</i> or <i>/bin/sh</i> in <i>/home/slitaz/cooking/arm/chroot</i> to start with?
And a native (armel) gcc, g++, readelf, ...?
2b. Can you post a full cook.conf for this? The cook.conf from arm.balinor.net/slitaz/armhf/ seems to be only for cross-compilation.
Offline
Ref:
http://forum.slitaz.org/topic/slitaz-arm#post-10798
http://forum.slitaz.org/topic/an-arm-gnulinux-box-for-25-take-a-byte#post-7129
Offline
1c. How does arm-slitaz-linux-gnueabi-* compare to other cross compilers such as arm-bcm2708-linux-gnueabi from
https://github.com/raspberrypi/tools/tree/master/arm-bcm2708
slitaz-armhf-cross-toolchain
slitaz-arm-toolchain-armhf-20120630.tar.bz2
Target: arm-slitaz-linux-gnueabi
--with-sysroot=/cross/arm/sysroot --with-arch=armv6 --with-fpu=vfp --with-float=hard
-march=armv6
-mfpu=vfp
-mfloat-abi=hard
These settings produce code with armv6 specific instructions, vector floating point instructions and specify the ARM EABI where floating point values are to be passed in floating point registers.
<b>I. RaspberryPi toolchain</b>
1. History for tools/arm-bcm2708
https://github.com/raspberrypi/tools/commits/master/arm-bcm2708
Jan 31, 2014
Update linaro gcc toolchain to: gcc-linaro-arm-linux-gnueabihf-raspbi… …
Aug 29, 2012
Add latest linaro gcc toolchain: gcc-linaro-arm-linux-gnueabihf-raspb… …
Aug 09, 2012
Rebuild with CT_KERNEL_VERSION=3.1.9
Jul 23, 2012
Rebuild toolchains with glibc 2.13 to match Wheezy image
3d08213d83341b274857c03b2e0795bffcd59715
Jul 21, 2012
Switch to 32-bit versions of gcc 4.7.1 for softfp and hardfp
ea20f345ee105aa89cce11bbcea0525940c38c93
Feb 03, 2012
Add 64 bit hardfp toolchain
3aba47b6f6004755d8b51cd042c4e6c9be64e2ad
Feb 01, 2012
Initial add of R-Pi toolchain
8740395dd92933bfc6ae1da88fd1492f7f194426
2.
R-Pi softfp toolchain
https://github.com/raspberrypi/tools/tree/3aba47b6f6004755d8b51cd042c4e6c9be64e2ad/arm-bcm2708/linux-x86/lib/gcc/arm-bcm2708-linux-gnueabi/4.5.1
64 bit hardfp toolchain
https://github.com/raspberrypi/tools/tree/3aba47b6f6004755d8b51cd042c4e6c9be64e2ad/arm-bcm2708/x86-linux64-cross-arm-linux-hardfp/lib/gcc/arm-bcm2708hardfp-linux-gnueabi/4.5.1
<b>II. Raspbian</b>
1. Raspbian packages
http://raspbian.org/
The initial build of over 35,000 Raspbian packages, optimized for best performance on the Raspberry Pi, was completed in June of 2012.
2. What is Raspbian?
http://raspbian.org/RaspbianFAQ#What_is_Raspbian.3F
Raspbian is an unofficial port of Debian wheezy armhf with compilation settings adjusted to produce code that uses "hardware floating point", the "hard float" ABI and will run on the Raspberry Pi.
The port is necessary because the official Debian wheezy armhf release is compatible only with versions of the ARM architecture later than the one used on the Raspberry Pi (ARMv7-A CPUs and higher, vs the Raspberry Pi's ARMv6 CPU).
The Debian squeeze image issued by the Raspberry Pi foundation was based on debian armel which uses software floating point and the "soft float" ABI. The foundation used the existing Debian port for less capable ARM devices. Therefore, it did not use of the Pi's processor's floating point hardware - reducing the Pi's performance during floating point intensive applications - or the advanced instructions of the ARMv6 CPU.
3. What compilation options should be set Raspbian code?
http://raspbian.org/RaspbianFAQ#What_compilation_options_should_be_set_Raspbian_code.3F
The compiler tools included in the Raspbian repository are, by default, pre-configured to produce code compatible with Raspbian. However, if you are looking to port compiler tools over to Raspbian, the settings required for most GNU tools are as follows:
-march=armv6
-mfpu=vfp
-mfloat-abi=hard
These settings produce code with armv6 specific instructions, vector floating point instructions and specify the ARM EABI where floating point values are to be passed in floating point registers. Additional information can be found in the Debian hard float documents.
http://wiki.debian.org/ArmHardFloatPort
Offline
Sorry, I've been busy with other stuff. Will try to actually do things in a few days.
http://forum.slitaz.org/topic/slitaz-arm#post-10798
But the end of that thread shows trouble compiling further into the toolchain.
http://forum.slitaz.org/topic/slitaz-arm/page/3#post-13032
So that way didn't work in the end? (Or rather, if they DID get eglibc working in the end, why isn't it in the repo
http://cook.slitaz.org/cross/arm/packages/
?)
Although I'm not there yet, I guess the next problem will be to get this glibc/eglibc. How did you even get an arm version of this??
http://forum.slitaz.org/topic/chroot/page/3#post-26285
Was your cross compiling tool enough to get this? (I still haven't tried yet.) Just
[c]-march=armv6
-mfpu=vfp
-mfloat-abi=hard[/c]
was enough? Also, I don't want -mfloat-abi=hard
I. RaspberryPi toolchain
1. History for tools/arm-bcm2708
I'm confused. Are you trying to tell me their version of glibc and gcc won't work with Slitaz? Or just trying to point at the compiler options to use?
I have otherwise no interest in Raspbian. Only Slitaz.
Offline
So that way didn't work in the end? (Or rather, if they DID get eglibc working in the end, why isn't it in the repo
http://cook.slitaz.org/cross/arm/packages/
?)
1. Summary
http://cook.slitaz.org/cross/arm/
Running command : Not running
Wok revision : 15854
[..]
Packages: 78 in the wok - 77 cooked - 1 unbuilt - Server date: 2014-02-18 14:07 CET
[..]
Latest cook
2014-01-28 20:07 : busybox-1.22.1-arm.tazpkg
2013-03-25 15:25 : tcc-0.9.25-arm.tazpkg
2013-03-25 15:25 : util-linux-whereis-2.21.1-arm.tazpkg
2013-03-25 15:25 : util-linux-mkfs-2.21.1-arm.tazpkg
2013-03-25 15:25 : dropbear-2012.55-arm.tazpkg
2013-03-25 15:24 : slitaz-base-files-5.4-arm.tazpkg
2013-03-25 15:24 : slitaz-boot-scripts-5.3.1-arm.tazpkg
2013-03-25 15:24 : cookutils-3.1.4-arm.tazpkg
[..]
2. Cross Toolchain
http://cook.slitaz.org/cross/arm/toolchain.cgi
Target host : arm
C Compiler : arm-slitaz-linux-gnueabi-gcc
CFLAGS : -march=armv6 -O2
Packages log: binutils eglibc gcc-final gcc-static linux-headers
testsuite.log
[COMPILING] arm-slitaz-linux-gnueabi-gcc -v -Wall -o test.out test.c
Using built-in specs.
COLLECT_GCC=arm-slitaz-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/cross/arm/tools/lib/gcc/arm-slitaz-linux-gnueabi/4.6.3/lto-wrapper
Target: arm-slitaz-linux-gnueabi
Configured with: ../gcc-4.6.3/configure --prefix=/cross/arm/tools --libexec=/cross/arm/tools/lib --target=arm-slitaz-linux-gnueabi --enable-shared --enable-c99 --enable-long-long --enable-__cxa_atexit --with-system-zlib --enable-plugin --disable-multilib --disable-libssp --disable-checking --disable-werror --with-pkgversion=SliTaz --with-bugurl=https://bugs.slitaz.org/ --with-sysroot=/cross/arm/sysroot --enable-languages=c,c++
Thread model: posix
gcc version 4.6.3 (SliTaz)
[..]
compile.log
Compile start: Tue Feb 11 23:01:52 CET 2014
Compile end : Wed Feb 12 01:00:06 CET 2014
Build time : 7094s ~ 118m
Offline
was enough? Also, I don't want -mfloat-abi=hard
I have otherwise no interest in Raspbian. Only Slitaz.
IMHO Raspbian is the best option for the Raspberry Pi.
1.
1. Raspbian packages
http://raspbian.org/
The initial build of over 35,000 Raspbian packages,
2. What is Raspbian?
http://raspbian.org/RaspbianFAQ#What_is_Raspbian.3F
2. Big News! Official Raspbian Image Released
http://raspbian.org/
The Raspberry Pi Foundation has produced and released their own recommended image of Raspbian.
3. Distro Super Test – Raspberry Pi Edition
MAY 3 by Rob Zwetsloot
http://www.linuxuser.co.uk/reviews/distro-super-test-pi-edition
We pit six Raspberry Pi operating systems against one another to find out which one is the king of the tiny computer distros
[..]
Raspbian
Your first port of call to get a Raspberry Pi going
[..]
Overall Score
9/10
Raspbian is a fantastic tool for teaching, general coding and all manner of home- grown projects. Definitely the best distro for beginners
[..]
SliTaz 4
A tiny distro supposedly for use on desktop and on server
[..]
Overall Score
4/10
SliTaz has a place as a very fast web server, but that is unfortunately all it can do without serious work
[..]
And the winner is…
Raspbian
A lot of these distros seemed to go back and forth between being as lightweight or as customisable as possible, or trying to offer a full desktop experience on the Pi. Raspbian goes the extra mile and not only supplies a great desktop experience, but is also heavily tied into the Raspberry Pi community. With access to learning modules and the Pi Store, it’s excellent for teaching computing, as well as for using in a headless state for a quick and easy-to-use server.
4. RPi Distributions
http://elinux.org/RPi_Distributions
5. RaspberryPi
https://wiki.debian.org/RaspberryPi
Can I put Debian on my Rasberry Pi?
Yes.
Debian armel will work, but will not make best use of the floating point hardware. Debian armhf will not work (see below).
If you know you need hardfloat support, your best bet is to use Raspbian - which is (mostly) Debian armhf rebuilt by members of Debian for the RPi's ARMv6+VFP2 ARM variant.
[..]
The CPU in the Raspberry Pi implements the ARMv6 ISA (with VFP2) and is thus incompatible with the Debian armhf port baseline of ARMv7+VFP3 and ARM hardware-floating-point ports for other distributions, which all have the same baseline. It is compatible with Debian armel (armv4t, soft(emulated) FP), but floating-point tasks will be slow when running the Debian armel port.
Offline
Ok, so I finally got some time to try stuff. I tried going panko's route.
[c]
root@host:/tmp# hg clone http://hg.slitaz.org/slitaz-arm
root@host:/tmp# cd slitaz-arm
root@host:/tmp/slitaz-arm# cd slitaz-arm
root@host:/tmp/slitaz-arm# ./sat mirror
root@host:/tmp/slitaz-arm# cp -a mirror/* packages/.
root@host:/tmp/slitaz-arm# ./sat gen --kmap --spk
[/c]
But now instead of going the ./sat emu route, I decided to use a copy of qemu-arm-static and just chroot, following your instructions from http://forum.slitaz.org/topic/chroot/page/3#post-26270
[c]
root@host:/tmp/slitaz-arm# cp /tmp/qemu-arm-static distro/usr/bin/qemu-arm-static
root@host:/tmp/slitaz-arm# chroot distro
root@host:/# uname -m
armv7l
root@host:/# tazpkg
/usr/bin/tazpkg: .: line 15: can't open '/usr/bin/gettext.sh'
[/c]
1a. Hmm...that's no good. Since its a shell script, I can copy my local copy of [c]/usr/bin/gettext.sh[/c] into [c]/tmp/slitaz-arm/distro[/c]. And tazpkg sort of works with lots of errors to [c]gettext: not found[/c]. And that's a binary.
Looking at http://cook.slitaz.org/cross/arm/, [c]gettext-base[/c] and [c]gettext[/c] are now broken.
Looking at your post http://forum.slitaz.org/topic/slitaz-on-armel#post-27986
Packages: 78 in the wok - 77 cooked - 1 unbuilt - Server date: 2014-02-18 14:07 CET
[..]
Compile start: Tue Feb 11 23:01:52 CET 2014
Compile end : Wed Feb 12 01:00:06 CET 2014
they were fine just a few days ago. Did something happen? (We are now down to
78 in the wok - 52 cooked - 26 unbuilt
)
1b. There's too many unrelated errors (about gettext, etc) with cook right now. (I sort of followed this http://forum.slitaz.org/topic/how-to-start-cooking#post-9533 and didn't bother with [c]tazdev[/c] since I was already in a chrooted environment.
[c]
root@host:/# mkdir -p /home/slitaz
root@host:/# cd /home/slitaz
root@host:/home/slitaz# cook setup
[/c]
(and then copied wok-stable to there.) But I can't cook anything because of the unrelated errors about missing binaries.
2. Is it supposed to be armv7l? Don't I need armv6 for the raspberry? Or is this coming from my version of qemu-arm-static?
3. [c]sat[/c] seem to have left [c]spk[/c] outside /tmp/distro instead of inside which is a bit odd. Although I was able to add it easily with
[c]
root@host:/tmp/slitaz-arm# cp -a spk distro
root@host:/tmp/slitaz-arm# chroot distro
root@host:/# cd spk
root@host:/spk# make
[/c]
Of course, packaging is the least of my worries right now.
Offline
So now
http://cook.slitaz.org/cross/arm/
is back to normal with all 78 packages built. Thank you! (Or whoever fixed the cooker.)
But there's no [c]eglibc[/c] or [c]gcc-final[/c] at http://cook.slitaz.org/cross/arm/packages/
The logs from http://cook.slitaz.org/cross/arm/toolchain.cgi says those five things
binutils eglibc gcc-final gcc-static linux-headers
were built successfully. But I can't find .tazpkg for them (or even source!) anywhere.
Google eventually lead me to this bitbucket repo https://bitbucket.org/godane/my-cookutils that I cloned. Looks like panko made a [c]./cross[/c] script in there that I'm using now.
But it looks like its trying to rebuild the whole thing. Since its already built in the cooker, is it possible to download a .tazpkg or even just the prebuilt binaries directly?
Also for anyone following this, there were a few mistakes in the commands in the last post. That will teach me to write commands from memory! I'll try to remember to go back and fix it once it works.
Offline
1.
The logs from http://cook.slitaz.org/cross/arm/toolchain.cgi says those five things
2. Cross Toolchain <====
http://cook.slitaz.org/cross/arm/toolchain.cgi
2.
bitbucket repo https://bitbucket.org/godane/my-cookutils that I cloned. Looks like panko made a ./cross script in there that I'm using now.
http://forum.slitaz.org/topic/chroot/page/3#post-27117
Offline
I. RaspberryPi toolchain
1. History for tools/arm-bcm2708
I'm confused. Are you trying to tell me their version of glibc and gcc won't work with Slitaz? Or just trying to point at the compiler options to use?
I. timestamps: Jun 30, 2012
1. RaspberryPi
1. History for tools/arm-bcm2708
Feb 03, 2012
Add 64 bit hardfp toolchain
3aba47b6f6004755d8b51cd042c4e6c9be64e2ad
2.
R-Pi softfp toolchain: gcc-4.5.1
64 bit hardfp toolchain:gcc-4.5.1
2. Raspbian:
32 bit hardfp toolchain:gcc-4.6.3
eglibc-2.13
3. Slitaz armhf:
slitaz-arm-toolchain-armhf-20120630.tar.bz2
32 bit hardfp toolchain:gcc-4.6.3
eglibc-2.13
4. SliTaz arm:
slitaz-arm-toolchain-20120519.tar.bz2 *
slitaz-arm-toolchain-20120529.tar.bz2 **
slitaz-arm-toolchain-20140212.tar.bz2 ***
32 bit softfp toolchain:gcc-4.6.3
eglibc-2.13
II. Receipt for: glibc-base
http://cook.slitaz.org/cross/arm/cooker.cgi?receipt=glibc-base
III. Installed files by: glibc-base
http://cook.slitaz.org/cross/arm/cooker.cgi?pkg=glibc-base
Offline
III. Installed files by: glibc-base
<del>http://cook.slitaz.org/cross/arm/cooker.cgi?pkg=glibc-base</del>
http://cook.slitaz.org/cross/arm/cooker.cgi?files=glibc-base
2. Raspbian:
32 bit hardfp toolchain:gcc-4.6.3
eglibc-2.13
3. Slitaz armhf:
slitaz-arm-toolchain-armhf-20120630.tar.bz2
32 bit hardfp toolchain:gcc-4.6.3
eglibc-2.13
1. tightvnc convert from Raspbian
http://archive.raspbian.org/raspbian/pool/main/t/tightvnc/tightvncserver_1.3.9-6.4_armhf.deb
TightVNC/Qt5
http://forum.slitaz.org/topic/chroot#post-22548
2. Qt5/qmake convert from twolife's Raspbian repository
http://twolife.be/raspbian/pool/qt/
Qt5-qmake/qtfm
http://forum.slitaz.org/topic/chroot#post-22551
5.
tux@slitaz:~$ tazpkg list | grep qt
libqt5 5.0.0-0rpi1 misc
libqt5-compositor 5.0.0~29-0rpi1 misc
libqt5-declarative 5.0.0-0rpi1 misc
libqt5-declarative-bin 5.0.0-0rpi1 misc
libqt5-dev-bin 5.0.0-0rpi1 misc
libqt5-graphicaleffects 5.0.0-0rpi1 misc
libqt5-multimedia 5.0.0-0rpi1 misc
libqt5-script 5.0.0-0rpi1 misc
libqt5-svg 5.0.0-0rpi1 misc
libqt5-tools 5.0.0-0rpi1 misc
libqt5-tools-bin 5.0.0-0rpi1 misc
libqt5-v8 5.0.0-0rpi1 misc
libqt5-xmlpatterns 5.0.0-0rpi1 misc
libqtwebkit5 5.0.0-0rpi1 misc
libqtwebkit5-bin 5.0.0-0rpi1 misc
qt5-demos-base 5 misc
qt5-demos-compositor 5.0.0~29-0rpi1 misc
qt5-qmake 5.0.0-0rpi1 misc
3.
root@slitaz:/tmp/qtfm-5.5# ls -l Makefile
-rw-r--r-- 1 root root 232653 Jan 13 03:57 Makefile
root@slitaz:/tmp/qtfm-5.5# head -21 Makefile
#############################################################################
# Makefile for building: qtfm
# Generated by qmake (3.0) (Qt 5.0.0) on: Sun Jan 13 03:57:53 2013
timestamps?
Offline
Hi,
SliTaz ARM cooker is up-to-date and I added a few packages to the repo.
@pirandr slitaz-arm/sat is just a small tool to generate an ARM distro using precompiled packages, but you dont need to put all mirrored packages into packages/. The basic one is enought to boot (8-10 packages), I will a add a list in the slitaz-arm repo.
Cross is a tool to build a cross toolchain from scratch but as you understoud you can use a precompiled version. To use it and compile stuff for arm you must/should create a build chroot with tazdev (avoid any gettext.sh and co errors) then install the toolchain (I must update the toolchain to 20140222 wich is curretly used in our ARM build env):
# tazdev gen-chroot --arch=arm
# tazdev chroot --arch=arm
# wget http://mirror.slitaz.org/packages/cross/
# tar xjf slitaz-cross-arm-toolchain*.tar.bz2
# cat slitaz-cross-arm-toolchain*/README
Then setup the cook env with 'cook arm-setup && cook setup --wok' to get the cooking wok in /home/slitaz/wok of the chroot. After that you can cook packages. Cook will not build packages if HOST_ARCH is not set in the receipt, this is done because we use the same wok for all arch.
I will soon get an Raspberry Pi so I will be able to improve SliTaz support for it. That said I would be very happy to get help and people involved in the Slitaz ARM port.
- Christophe
Offline
Few more info
I use Eglibc with cross to build the ARM cross toolchain and used the glibc-base package to provide libc in ARM. It's a trick to simplify packaging with cook but I guess we will add eglibc packages in time.
I did NOT try native compilation with qemu-arm-static but it may be easier to build SliTaz ARM, so I will investigate.
I also plan to setup arm.slitaz.org to provide all ARM related infos, links and howto's.
@alanyih Can you put online or send me the armhf wok with patches (I tried to cross bluid glib using your modified receipt but I'm missing patches)
Offline
Sorry for the slow replies (but its likely the speed at which I can work...). Compilation takes time and mistake are a bit more costly time-wise (but I don't mind
).
@alanyih: I never answered some of your earlier questions/replies so let me do that now which things compiling in the background.
1. Regarding Raspbian
IMHO Raspbian is the best option for the Raspberry Pi.
I certainly agree that it is much easier to get started there and there's quite a bit of documentation for Raspbian. However, I found that Raspbian was running rather slowly on my Raspberry Pi. I don't think such slow speed is justified. I ran a computer with similar specs for many years (well, with the possible exception of the GPU but that's because we don't understand the Raspberry GPU very well) and it was fast.
I was running gnome, gdm, firefox with no slowdown. The only "secret" is that I used an older distribution.
However, with Debian variants, I cannot go back too far in the past since ARM was not yet supported. So I cannot even test my hypothesis (that using some well chosen old versions of software will give me the speed gain I seek).
But SliTaz has a fairly strong anti-bloat policy. I've been keeping in my pocket as a backup system for years now. And I love it. I was originally drawn by its boot speed. But now I realise taht I like how you can choose which large programs you want to use and which ones you do. I like the fact that (almost?) all tools are script so they are portable and its possible to easily understand what's going on (and customize them easily without too much trouble). My biggest gripe was that I couldn't get my wireless card working but this is no longer an issue in 4.0.
So that's why I tried to move from Raspbian to SliTaz.
2. Toolchain history
Thanks for clarifying that. Now I know you were talking about the dates that the cross-compilation tools were released.
Although as you may deduce from 1., I don't think that newer is always necessarily better. (But I'm still very happy you pointed out this fact.) Although I was not able to find a [c]slitaz-arm-toolchain-20140212.tar.bz2[/c] anywhere. I was mentioned in this post.
4. SliTaz arm:
slitaz-arm-toolchain-20120519.tar.bz2 *
slitaz-arm-toolchain-20120529.tar.bz2 **
slitaz-arm-toolchain-20140212.tar.bz2 ***
32 bit softfp toolchain:gcc-4.6.3
eglibc-2.13
3. glibc-base receipts and files
Thanks! Although that was already in the mirror I got from [c]sat[/c]. I guess what I mean is that I was trying to get a working native copy of gcc and dependencies.
4. TightVNC and qt
I don't quite understand why we started talking about this already. I haven't gotten a compile xserver at the moment! Maybe you are just looking one step ahead?
Offline
@pankso: I'm so very glad that you are joining this conversation.
Can you summarize the state of advancement? Or is the arm repo representative of it?
And could you confirm that the arm repo is indeed armel (and not armhf)?
From the updated ARM repo (thanks for that!), it looks like there are some packages for Xorg (but no xorg-server). Does this mean there is a working copy of X now? Or not quite.
I did NOT try native compilation with qemu-arm-static but it may be easier to build SliTaz ARM, so I will investigate.
I see a [c]gcc-lib-base[/c] but no [c]gcc[/c]. I guess there's no binary yet? I thought that godane's tool is supposed to yield a native gcc binary. (It requires a cross compiler so it can give another cross-compiler, right?)
@pirandr slitaz-arm/sat is just a small tool to generate an ARM distro using precompiled packages, but you dont need to put all mirrored packages into packages/.
Thanks for the clarification! Although I did want as much as possible since it was fairly small even then (and I didn't want to spend the time accidentally compile a package that was already available; there's enough unavailable ones to make!)
Offline
Ok, so I went ahead with a clean cross-compile environment (since native compilation doesn't seem to be quite there yet).
# tazdev gen-chroot --arch=arm
# tazdev chroot --arch=arm
# wget http://mirror.slitaz.org/packages/cross/
# tar xjf slitaz-cross-arm-toolchain*.tar.bz2
# cat slitaz-cross-arm-toolchain*/README
Then setup the cook env with 'cook arm-setup && cook setup --wok' to get the cooking wok in /home/slitaz/wok of the chroot. After that you can cook packages. Cook will not build packages if HOST_ARCH is not set in the receipt, this is done because we use the same wok for all arch.
For those following, that wget line actually requires look into the directory and downloading the only file in there
# wget http://mirror.slitaz.org/packages/cross/
and the export in [c]slitaz-cross-arm-toolchain*/README[/c] should be
export PATH=$PATH:/usr/cross/bin
instead of
export PATH=$PATH:/usr/cross
There seemed to be some other path issues with this version of cross to which I just applied some hacky fix
[c]<br />
$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/cross/i686-pc-linux-gnu/arm-slitaz-linux-gnueabi/lib/<br />
$ ln -s /usr/cross arm<br />[/c]
I cooked [c]m4[/c] just to test and it worked fine. But couldn't get [c]xz[/c] to cook. This error is probably what's stopping [c]configure[/c] right now:
arm-slitaz-linux-gnueabi-gcc: error: unrecognized option '-qlanglvl=extc99'
Edit:
I will soon get an Raspberry Pi so I will be able to improve SliTaz support for it. That said I would be very happy to get help and people involved in the Slitaz ARM port.
I guess this should have been one of the first things for me to test but I just tried the all-packages [c]sat[/c] generated version on the Raspberry Pi and it boots without issue (I did try alanyih's armhf image a long time ago and that worked too).
Offline
I thought that godane's tool is supposed to yield a native gcc binary. (It requires a cross compiler so it can give another cross-compiler, right?)
Well, I answered my own question there. The [c]/cross[/c] in [c]WORK=/cross[/c] of [c]cross.conf[/c] was the target directory, not the source so this does indeed build a cross-compilation tool.
Still, even the [c]arm-slitaz-linux-gnueabi-gcc[/c] built from [c]my-cookutil[/c] gives a [c]unrecognized option '-qlanglvl=extc99'[/c] error. (I got [c]binutil[/c] and [c]gcc-static[/c] to build this way, but not the rest.)
Offline
slitaz-arm-toolchain-20120519.tar.bz2 *
slitaz-arm-toolchain-20120529.tar.bz2 **
slitaz-arm-toolchain-20140212.tar.bz2 ***
slitaz-arm-toolchain-armhf-20120630.tar.bz2
http://forum.slitaz.org/topic/chroot/page/3#post-27117
># wget http://mirror.slitaz.org/packages/cross/
SliTaz uses the sysroot method
1. cross howto
tux@slitaz:~$ cross howto | head
SYNOPSIS
cross [command|package] package
DESCRIPTION
Cross is a tool to build a cross toolchain on SliTaz GNU/Linux. The
ARM platform is actually supported and a x86_64 toolchain is on the
stove
COMMANDS
2. Cross - Help build a cross toolchain on SliTaz.
cookutils changeset 361:e7e7979eb49d
http://hg.slitaz.org/cookutils/rev/e7e7979eb49d
Add cross (let have a cross toolchain builder)
author Christophe Lincoln <pankso@slitaz.org>
date Wed May 09 22:15:39 2012 +0200 (21 months ago ago)
[..]
diff -r c75f13234af0 -r e7e7979eb49d cross
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/cross Wed May 09 22:15:39 2012 +0200
@@ -0,0 +1,272 @@
+#!/bin/sh
+#
+# Cross - Help build a cross toolchain on SliTaz.
+#
+# Copyright 2012 (C) SliTaz GNU/Linux - BSD License
+# Author: Christophe Lincoln <pankso@slitaz.org>
3. Create a prebuilt cross toolchain tarball.
http://hg.slitaz.org/cookutils/file/3f5c9e87f05d/cross
448 gen-prebuilt)
449 # Create a prebuilt cross toolchain tarball.
450 init_compile
451 date=$(date "+%Y%m%d")
452 package="slitaz-$ARCH-toolchain-$date"
453 tarball="$package.tar.bz2"
4. SliTaz uses the sysroot method
( 1). cook.conf
http://hg.slitaz.org/cookutils/file/3f5c9e87f05d/cook.conf
51 # SliTaz uses the sysroot method, this tells GCC to consider dir as the root
52 # of a tree that contains a (subset of) the root filesystem of the target
53 # operating system. Target system headers, libraries and run-time object
54 # files will be searched in there. Cook will use the tools and sysroot in
55 # the CROSS_TREE for cross compiling. Example: CROSS_TREE="/cross/$ARCH"
(2) .Cook log
http://cook.slitaz.org/cross/arm/cooker.cgi?pkg=linux
Cook: linux 3.2.53
================================================================================
arm sysroot: /cross/arm/sysroot
Adding /cross/arm/tools/bin to PATH
Using cross-tools: arm-slitaz-linux-gnueabi-
QA: checking package receipt...
QA: unable to reach: http://www.kernel.org/
Checking build dependencies...
Using packages DB: /cross/arm/sysroot/var/lib/tazpkg
Extracting: linux-3.2.53.tar.xz
Executing: compile_rules
CFLAGS : -march=armv6 -O2
Compiling: arm Kernel
(3). slitaz-arm-toolchain-20120519.tar.bz2 * (deprecated)
http://mirror.slitaz.org/packages/cross/slitaz-cross-arm-toolchain-20120519.tar.bz2
--prefix=/usr/cross/arm --libexec=/usr/cross/arm/lib
(4).
slitaz-arm-toolchain-20120529.tar.bz2 **
slitaz-arm-toolchain-20140212.tar.bz2 ***
slitaz-arm-toolchain-armhf-20120630.tar.bz2
--prefix=/cross/arm/tools --libexec=/cross/arm/tools/lib --sysroot=/cross/arm/sysroot
Offline
2b. Can you post a full cook.conf for this? The cook.conf from arm.balinor.net/slitaz/armhf/ seems to be only for cross-compilation.
1. Fixed. Thanks.
http://arm.balinor.net/slitaz/armhf/packages/cookutils-2.0-armhf.tazpkg
# Target host architecture type (Glibc doesn't support i386 anymore).
ARCH="arm"
2. SliTaz arm
2013-03-25 15:24 : cookutils-3.1.4-arm.tazpkg
cookutils-3.2-arm.tazpkg 2014-Feb-18 23:46:38
http://cook.slitaz.org/cross/arm/packages/cookutils-3.2-arm.tazpkg
cook.conf
http://cook.slitaz.org/cross/arm/cooker.cgi?download=../wok/cookutils/taz/cookutils-3.2/fs/etc/slitaz/cook.conf
# Target host architecture type (Glibc doesn't support i386 anymore).
ARCH="i486"
Offline
3. Distro Super Test – Raspberry Pi Edition
http://www.linuxuser.co.uk/reviews/distro-super-test-pi-edition
SliTaz 4
A tiny distro supposedly for use on desktop and on server
Overall Score
4/10
SliTaz has a place as a very fast web server, but that is unfortunately all it can do without serious work
>So that's why I tried to move from Raspbian to SliTaz.
Have any idea?
SliTaz 4
A tiny distro supposedly for use on desktop and on server
With the smallest image in the test, SliTaz is quick to download, install and boot. In fact, it shows off on startup that it took only three seconds to get to the command line – the fastest in this test. SliTaz is in its fourth version, released in the middle of last year. As an independent distro, not based on anything else, it is one of the genuine few that support hard float operations without being based on Raspbian. Clocking in at only 500MB on the SD card, it’s certainly a feat to have this fully working system on the Pi.
That low storage footprint comes at a price, though: there isn’t much to SliTaz. Coming with a grand total of 17 packages pre-installed, it’s an incredibly lightweight system that the developers themselves admit is meant to eke the max out of the Pi. The problem is, while the full SliTaz repos have a decent selection of packages, the Pi version only has 268. These are mostly utilities, and you can’t install a desktop environment from the repos. However, there is access to Xorg, and all the tools needed to compile it yourself. SliTaz has its own package manager, tazpkg, with a good search function to find what packages are available in lieu of a graphical manager. While you can also search the website for packages, you can’t filter by what’s available on Pi or not.
SliTaz on Pi then is very focused on being used as some kind of headless server, and admittedly thanks to the lack of packages it is fast, and it will draw very little power. The problem is, something like Arch is basically as fast, and the repositories are full of software that will allow you to also make it into a server. Also, you can also very easily turn Arch into a desktop system, something that SliTaz is very noticeably lacking.
SliTaz definitely has its place, and as a server it is quick to set up and has a lower footprint than the others. It just lacks the flexibility inherent in the Raspberry Pi itself.
Overall Score
4/10
SliTaz has a place as a very fast web server, but that is unfortunately all it can do without serious work
Offline
Now that I've fixed my misunderstanding of what [c]cross[/c] does (despite being told this many time! Sorry about that.), I can finally make sense of this.
Still, no-one has posted a newer version of the prebuilt toolchain so for the moment I'm still on
http://mirror.slitaz.org/packages/cross/slitaz-cross-arm-toolchain-20120519.tar.bz2
Can someone [c]gen-prebuild[/c] on the cooker and post the package from there? If nobody does and I'm successful, I'll post my prebuild, of course.
Although the half build I did manage to make (which should be an up-to-date version, I think) didn't seem to make much of a difference for cooking (at least I wasn't able to build all the packages that the cooker at http://cook.slitaz.org/cross/arm/ is able to) and that seems rather odd to me.
I'm going to try a full build from the chrooted system this time just to make sure.
Although I wish the tool wouldn't clobber everything and start over every time there's an error (and just continue from the last configure/make line).
1. Fixed. Thanks.
http://arm.balinor.net/slitaz/armhf/packages/cookutils-2.0-armhf.tazpkg
# Target host architecture type (Glibc doesn't support i386 anymore).
ARCH="arm"
2. SliTaz arm
2013-03-25 15:24 : cookutils-3.1.4-arm.tazpkg
cookutils-3.2-arm.tazpkg 2014-Feb-18 23:46:38
http://cook.slitaz.org/cross/arm/packages/cookutils-3.2-arm.tazpkg
cook.conf
http://cook.slitaz.org/cross/arm/cooker.cgi?download=../wok/cookutils/taz/cookutils-3.2/fs/etc/slitaz/cook.conf
# Target host architecture type (Glibc doesn't support i386 anymore).
ARCH="i486"
Thanks for posting this! Sadly, I now realised there isn't a native gcc (and other build tools) anywhere
>So that's why I tried to move from Raspbian to SliTaz.
Have any idea?
I'm not sure what you mean. Do you mean
- "Any idea why SliTaz is rated so low?" (The main concern seems to be the availability of programs.)
- "Any idea how to fix the problems mentioned here?" (Well, make more packages available, I guess...)
- "Any idea how to make more things available?" (Well, I guess that's what we are doing now. Hopefully, I can just focus on where you all got stuck last time and don't have to redo too much of what's already known to get there.)
Offline
So I've finally build the cross compilation tool from [c]cross[/c] (the one included in [c]cookutils[/c] this time).
A quick note:
On arm, [c]eglibc[/c] compilation is run as part of [c]cross compile[/c] and [c]cross eglibc[/c] is a possible but it is not documented in usage for [c]cross[/c].
This is probably something you all already have but here's the result
https://github.com/pirandr/slitaz-arm
I also put the eglibc source there so that its possible to build the cross compilation tools without [c]svn[/c] (by manually copying those archives to [c]/home/slitaz/src[/c]). Of course, this will only work until versions change.
And so I went on to try and build [c]xz[/c] this time and it worked again. Looking at the online cooker, it looks like you were trying to build [c]libxslt[/c] so I though I might give it a try. I went ahead and built
libxml2 libxml2-dev zlib zlib-dev
And then ran
cook libxslt
I see
[c]<br />
root@hostname:/home/slitaz# cook libxslt</p>
<p>Cook: libxslt 1.1.26<br />
================================================================================<br />
arm sysroot: /cross/arm/sysroot<br />
Adding /cross/arm/tools/bin to PATH<br />
Using cross-tools: arm-slitaz-linux-gnueabi-<br />
QA: checking package receipt...<br />
Checking build dependencies...<br />
Using packages DB: /cross/arm/sysroot/var/lib/tazpkg<br />
Installing dep (pkg/local): libxml2-dev-2.8.0-arm.tazpkg<br />
Connecting to mirror.slitaz.org (46.105.127.17:80)<br />
zlib-1.2.8.tazpkg 100% |*******************************| 35924 0:00:00 ETA<br />
Connecting to mirror.slitaz.org (46.105.127.17:80)<br />
glibc-base-2.14.1.ta 100% |*******************************| 1270k 0:00:00 ETA<br />
Installing dep (pkg/local): libxml2-2.8.0-arm.tazpkg<br />
Connecting to xmlsoft.org (176.31.99.103:21)<br />
libxslt-1.1.26.tar.g 100% |*******************************| 3321k 0:00:00 ETA<br />
Extracting: libxslt-1.1.26.tar.gz<br />
Executing: compile_rules<br />
CFLAGS : -march=armv6 -O2<br />
configure: loading site script /etc/slitaz/cook.site<br />
checking build system type... i486-slitaz-linux-gnu<br />
checking host system type... arm-slitaz-linux-gnueabi<br />
checking for arm-slitaz-linux-gnueabi-gcc... arm-slitaz-linux-gnueabi-gcc<br />
checking for C compiler default output file name...<br />
configure: error: in[/c]
/home/slitaz/wok/libxslt/source/libxslt-1.1.26':
configure: error: C compiler cannot create executables
See `config.log' for more details.<br />
Build dependencies to remove: 6<br />
Removing: glibc-base/usr/bin/tazpkg: line 139: dirname: not found<br />
/usr/bin/tazpkg: line 139: dirname: not found<br />
`
before an avalanche of errors. [c]tazpkg: not found[/c] That can't be right. I try to run it and indeed its not there anymore. I get out of the chrooted environment but can't go back in!
chroot: can't execute '/bin/sh': No such file or directory
Bullshit! [c]/bin/sh[/c] is there and I can certainly run it directly from the outer system. I suspect that glibc of the chrooted system got removed (as the last lines suggest) instead of glibc in [c]/cross/arm/sysroot[/c].
Edit: And here's the kicker, the configuration error was
[c]
/cross/arm/tools/lib/gcc/arm-slitaz-linux-gnueabi/4.6.3/../../../../arm-slitaz-
linux-gnueabi/bin/ld: skipping incompatible /cross/arm/sysroot/lib/libc.so.6 wh
en searching for /lib/libc.so.6
/cross/arm/tools/lib/gcc/arm-slitaz-linux-gnueabi/4.6.3/../../../../arm-slitaz-
linux-gnueabi/bin/ld: cannot find /lib/libc.so.6 inside /cross/arm/sysroot
[/c]
That's right, it couldn't find libc!
Offline
I also just noticed that when I ran [c]cook arm-setup[/c], I got the warning
WARNING: (e)glibc-base is not installed in sysroot
But I think eglibc is installed in [c]/cross/arm/sysroot[/c]. Its just that there's not receipt at [c]/cross/arm/sysroot/var/lib/tazpkg/installed/glibc-base/receipt[/c] (obviously since it wasn't installed by tazpkg). However, I'm thinking this is still confusing cook and its trying to install another glibc from mirror.slitaz.org when it can't find one?
I use Eglibc with cross to build the ARM cross toolchain and used the glibc-base package to provide libc in ARM.
How do I "use" the glibc-base package in this way? (How do I tell [c]arm-setup[/c] that this is what it should do?)
Offline
[ Generated in 0.018 seconds, 7 queries executed - Memory usage: 1.66 MiB (Peak: 1.77 MiB) ]