SliTaz Forum
You are not logged in.
Bash book: "The Linux Command Line" (freely downloadable) I haven't finished "The Debian Administrator's Handbook" yet, but that book seems good and up to date, and the author seems very engaged.
Offline
But YouTube tutorials might be an option too.
Offline
Well....
quite embarassing to realize, that Pankso had the cross-toolchain ready already 5 years ago and I simply didn't understand what was directly in front of my eyes...
But that may also depend on the fact, that the [c]cross compile[/c] script halted with errors in my config all the time and I wasn't able to grab the faults.
Now that I invested some time into "Cross Linux from scratch" I found the bug that intimidated me (and maybe others, too). In addition, I patched [c]cross.conf[/c] and [c]/usr/bin/cross[/c]. As a first step, I took the packages, that CLFS uses in the latest version (apart from the Kernel) and want to step ahead from there...
So what did I do?
1.) I changed the command order in [c]/usr/bin/cross[/c] in the procedure `compile.
glibc-headers depends on the Kernel headers being present. In the script, glibc_headers was called BEFORE kernel_headers. Changing the order leads to a working compilation.
2.) I copied the line to identify the number of possible threads into the script: [c]THREADS=$(grep processor /proc/cpuinfo | wc -l)[/c]and added the parameter to the [c]make[/c] commands ([c]make -j$THREADS[/c])
3.) Since tar is able to identify the correct decompressor by itself, I changed the [c]tar -x[j|J]f[/c] commands to simply [c]tar -xf[/c], gaining some flexibility for a change of provided source packages.
4.) Due to the updated sources, the [c]--enable-kernel=[/c] parameter for glibc compilation was changed to the minimum version of 3.12.0 (as documented in CLFS).
5.) I changed [c]/etc/slitaz/cross.conf[/c]to contain the updated version information.
With these settings, I am reliably able to produce a cross-toolchain that cooks x86_64 tazpkgs.
!!! BUT BEWARE !!!
Using this toolchain and the available x86_64 receipts in the wok, some of the packages are produced flawlessly (beginning with m4, the compressors and more). But some others (like bison) BREAK THE SYSTEM COMPLETELY during the optimisation of the package by deleting most of the system files.
SO USE THIS ON A SYSTEM RUNNING IN RAM ONLY, NOT ON A HD-INSTALLED ONE!
I guess we will have to dig deeper into the cook scripts to find that one...
I'll post the patches in a minute...
Offline
[c]--- /etc/slitaz/cross.conf
+++ /media/Daten/Slitaz64_bootstrap/source/../slitaz-cross/cross.conf
@@ -12,11 +12,11 @@
SRC=/home/slitaz/src
# Cross-tools versions
-BINUTILS_VERSION="2.22"
-LINUX_VERSION="3.2.14"
-GLIBC_VERSION="2.14.1"
-GCC_VERSION="4.6.3"
-LIBTOOL_VERSION="2.4.2"
+BINUTILS_VERSION="2.28"
+LINUX_VERSION="5.10.3"
+GLIBC_VERSION="2.25"
+GCC_VERSION="7.1.0"
+LIBTOOL_VERSION="2.4.6"
# Per package configure arguments
BINUTILS_ARGS="--disable-multilib --enable-64-bit-bfd"[/c]
Offline
[c]--- /usr/bin/cross
+++ /media/Daten/Slitaz64_bootstrap/slitaz-cross/cross
@@ -11,6 +11,7 @@
[ -f "/etc/slitaz/cross.conf" ] && . /etc/slitaz/cross.conf
[ -f "cross.conf" ] && . ./cross.conf
+THREADS=$(grep processor /proc/cpuinfo | wc -l)
# Handle --config=/path/to/cross.conf
@@ -25,7 +26,7 @@
binutils_tarball="binutils-$BINUTILS_VERSION.tar.bz2"
linux_tarball="linux-$LINUX_VERSION.tar.xz"
-glibc_tarball="glibc-$GLIBC_VERSION.tar.bz2"
+glibc_tarball="glibc-$GLIBC_VERSION.tar.xz"
eglibc_tarball="eglibc-$EGLIBC_VERSION.tar.bz2"
gcc_tarball="gcc-$GCC_VERSION.tar.bz2"
libtool_tarball="libtool-$LIBTOOL_VERSION.tar.gz"
@@ -34,12 +35,12 @@
# Cross-tools URLs
binutils_wget="http://ftp.gnu.org/gnu/binutils/$binutils_tarball"
-linux_wget="http://www.kernel.org/pub/linux/kernel/v3.x/$linux_tarball"
+linux_wget="http://www.kernel.org/pub/linux/kernel/v5.x/$linux_tarball"
glibc_wget="http://ftp.gnu.org/gnu/libc/$glibc_tarball"
eglibc_wget="http://mirror.slitaz.org/arm/src/$eglibc_tarball"
eglibc_svn="svn://svn.eglibc.org/branches/eglibc-2_14"
gcc_wget="http://ftp.gnu.org/gnu/gcc/gcc-$GCC_VERSION/$gcc_tarball"
-libtool_wget="ftp://sunsite.cnlab-switch.ch/mirror/gnu/libtool/$libtool_tarball"
+libtool_wget="https://ftpmirror.gnu.org/libtool/$libtool_tarball"
# Help and usage.
@@ -141,7 +142,7 @@
init_compile
rm -rf binutils-$BINUTILS_VERSION
echo "Extracting: $binutils_tarball"
- tar -xjf $SRC/$binutils_tarball
+ tar -xf $SRC/$binutils_tarball
echo "Configure: $BINUTILS_ARGS"
cd binutils-$BINUTILS_VERSION
./configure \
@@ -152,7 +153,7 @@
--enable-targets=$BUILD_SYSTEM \
--with-sysroot=$sysroot \
$BINUTILS_ARGS &&
- make || exit 1
+ make -j${THREADS} || exit 1
make install
echo "cross: binutils compiled on: $(date)"
}
@@ -164,7 +165,7 @@
init_compile
if [ ! -d "linux-$LINUX_VERSION" ]; then
echo "Extracting: $linux_tarball"
- tar -xJf $SRC/$linux_tarball
+ tar -xf $SRC/$linux_tarball
fi
case "$ARCH" in
armv6hf) KARCH='arm' ;;
@@ -188,7 +189,7 @@
glibc_headers() {
init_compile
echo "Extracting: $glibc_tarball"
- tar -xjf $SRC/$glibc_tarball
+ tar -xf $SRC/$glibc_tarball
rm -rf glibc-headers
mkdir glibc-headers; cd glibc-headers
libc_cv_forced_unwind=yes \
@@ -199,7 +200,7 @@
--with-headers=$sysroot/usr/include \
--without-cvs \
--disable-sanity-checks \
- --enable-kernel=2.6.32 &&
+ --enable-kernel=3.12.0 &&
make -k install-headers install_root=$sysroot
# Fixes
mkdir -p $sysroot/usr/include/gnu
@@ -216,7 +217,7 @@
gcc_static() {
init_compile
echo "Extracting: $gcc_tarball"
- tar -xjf $SRC/$gcc_tarball
+ tar -xf $SRC/$gcc_tarball
echo "Configure: $GCC_STATIC_ARGS"
rm -rf gcc-static
mkdir gcc-static; cd gcc-static
@@ -233,7 +234,7 @@
--with-newlib \
--with-sysroot=$sysroot \
$GCC_STATIC_ARGS &&
- make all-gcc all-target-libgcc || exit 1
+ make -j${THREADS} all-gcc all-target-libgcc || exit 1
make install-gcc install-target-libgcc
echo "cross: gcc-static compiled on: $(date)"
}
@@ -244,7 +245,7 @@
glibc() {
init_compile
echo "Extracting: $glibc_tarball"
- tar -xjf $SRC/$glibc_tarball
+ tar -xf $SRC/$glibc_tarball
echo "Configure: $GLIBC_ARGS"
# Some arch may need glibc-ports and custom CFLAGS
case "$ARCH" in
@@ -255,7 +256,7 @@
-O $SRC/glibc-ports-$GLIBC_VERSION.tar.bz2 || exit 1
echo "Extracting: glibc-ports-$GLIBC_VERSION.tar.bz2"
rm -rf glibc-$GLIBC_VERSION/ports
- tar -xjf $SRC/glibc-ports-$GLIBC_VERSION.tar.bz2
+ tar -xf $SRC/glibc-ports-$GLIBC_VERSION.tar.bz2
mv glibc-ports-$GLIBC_VERSION glibc-$GLIBC_VERSION/ports
libexec='/usr/lib/glibc' ;;
x86_64)
@@ -283,9 +284,9 @@
--host=$TARGET \
--with-headers=$sysroot/usr/include \
--with-binutils=$tools/bin \
- --enable-kernel=2.6.32 \
+ --enable-kernel=3.12.0 \
$GLIBC_ARGS &&
- make || exit 1
+ make -j${THREADS} || exit 1
make install_root=$sysroot install
# Symlink lib64 to lib
case "$ARCH" in
@@ -309,7 +310,7 @@
exit 1
fi
echo "Extracting: $eglibc_tarball"
- tar -xjf $SRC/$eglibc_tarball || exit 1
+ tar -xf $SRC/$eglibc_tarball || exit 1
case "$ARCH" in
arm*)
if [ ! -d "$source/eglibc-ports-$EGLIBC_VERSION" ]; then
@@ -352,7 +353,7 @@
--without-cvs \
--cache-file=config.cache \
$EGLIBC_ARGS &&
- make || exit 1
+ make -j${THREADS} || exit 1
make install_root=$sysroot install || exit 1
# Sep files for packaging
make install_root=$source/eglibc-install install || exit 1
@@ -366,7 +367,7 @@
init_compile
if [ ! -d "gcc-$GCC_VERSION" ]; then
echo "Extracting: $gcc_tarball"
- tar -xjf $SRC/$gcc_tarball
+ tar -xf $SRC/$gcc_tarball
fi
echo "Configure: $GCC_FINAL_ARGS"
rm -rf gcc-build
@@ -390,7 +391,7 @@
--with-bugurl="http://bugs.slitaz.org/" \
--with-sysroot=$sysroot \
$GCC_FINAL_ARGS &&
- make AS_FOR_TARGET="${TARGET}-as" \
+ make -j${THREADS} AS_FOR_TARGET="${TARGET}-as" \
LD_FOR_TARGET="${TARGET}-ld" || exit 1
make install
echo "cross: GCC final compiled on: $(date)"
@@ -404,14 +405,14 @@
[ "$clean" ] && rm -rf libtool-${LIBTOOL_VERSION}
if [ ! -d "libtool-$LIBTOOL_VERSION" ]; then
echo "Extracting: $libtool_tarball"
- tar -xzf $SRC/$libtool_tarball
+ tar -xf $SRC/$libtool_tarball
fi
cd libtool-${LIBTOOL_VERSION}
./configure \
--prefix=$tools \
--host=${TARGET} \
--program-prefix=${TARGET}- &&
- make || exit 1
+ make -j${THREADS} || exit 1
make install
echo "cross: Cross libtool compiled on: $(date)"
}
@@ -526,10 +527,10 @@
echo "Compile start: $(date)" | tee $logdir/compile.log
download_src
binutils 2>&1 | tee $logdir/binutils.log
+ linux_headers 2>&1 | tee $logdir/linux-headers.log
case "$ARCH" in
x86_64) glibc_headers 2>&1 | tee $logdir/glibc-headers.log ;;
esac
- linux_headers 2>&1 | tee $logdir/linux-headers.log
gcc_static 2>&1 | tee $logdir/gcc-static.log
case "$ARCH" in
arm*) eglibc 2>&1 | tee $logdir/eglibc.log ;;[/c]
Offline
(Sorry to upload the patches like this, I'm somehow failing to upload these at github and the files are still not accepted as .txt...)
Offline
I was astonished, too.
I tried to stick to the slitaz universe by building the toolchain with cook, so i would not break anything.
m4 for example builds fine into a 106.5K package, reporting:
[c]Summary for: m4 1.4.18
=========================================
Source dir : 16.4M
Src file : m4-1.4.18.tar.gz
Src size : 1.9M
Produced : 628.0K
Packed : 276.0K
Compressed : 106.4K
Files : 1
Cook time : 24s
Cook date : 2021-01-17 18:58
Host arch : x86_64
=========================================[/c]
Checking the m4 binary reports:
[c]m4: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.12.0, with debug_info, not stripped[/c]
so,at first glance, everything seems to be fine...
When cooking bison, the download, configure, make and make install processes run through fine.
After that, "Compressing man pages" reports "Done" and no error.
Then, at "Normalizing mo files", there's the warning, (for lines 6 and 9 coming again and again):
[c]awk: cmd. line:9: warning: regexp escape sequence '\"' is not a known regexp operator[/c]
till it says "Done, Time: 17.70s. Size: 666986 B -> 610823 B. Save: 55 KB."
After that,
[c]/usr/libexec/tazpkg/remove: line 116: busybox: not found[/c],
as well as other error messages about non-findable files (libtaz.sh, /usr/lib/tazpkg/bb, gettext)
Then, neither the command line nor the system accept any commands, even shutdown is not possible anymore.
(I'm writing this in exactly that state, only SeaMonkey still working until hard shutdown...)
So I understand how a chroot is working, but it seems to me, that something is broken after the chroot has already been left again...
Offline
... found through debug (bash -x cook bison), that while cleaning up the dependencies, the root entry ist missing:
[c]tazpkg remove glibc-base --root=[/c]
This removes glibc-base, killing the rest of the system...
Investigating further...
Offline
I ran into busybox-1.31.1 failure during a package update.
In this scenario the problem is due to busybox-1.31.1 being linked to /usr/lib/libgcc_s.so.1 which is owned by both gcc-lib-base and gcc49-lib-base.
When tazpkg updates gcc49-lib-base,the pre-install script renames libgcc_s.so.1 to libgcc_s.so.1.prev which breaks the libs link to busybox.
To fix required booting into another linux, mounting the slitaz partition.
Renaming /usr/lib/libgcc_s.so.1.prev to libgcc_s.so.1
After booting back into slitaz I blocked both gcc-lib-base and gcc49-lib-base from updating to prevent a repeat of the problem on future updates.
Offline
Commenting out line 544 in remove_deps() subroutine, which is
[c]echo 'y' | tazpkg remove $dep --root=$root >/dev/null[/c]
leads to an unbroken cooking.
So somehow (although defined in cookit() line 575 as root=$sysroot for x86_64 Arch) $root is empty, leading to the removal of deps in the host system.
Changing line 544 to --root=$sysroot seems to solve the problem at first glance...
Offline
@shann:
Hello. I was the OP of this thread.
I see this thread is turning into dev-focused, so since I'm unfortunately no dev, I'll not be pestering here.
Just wanted to ask, I see your other thread https://forum.slitaz.org/topic/future-of-slitaz
Could this mean that work on Slitaz project may be re-taken in a few months?
Could this mean there's now actual hope for an overall updated Slitaz x64?
Current Slitaz 5.0 is already suffering the pass of time. Several applications are ceasing to work.
For example, Aleksej already mentioned the case of Firefox; and now Pale Moon browser has stopped releases of x86 versions on Linux...
Thanks.
Offline
Hi guest_account,
Infact in few months i begin work on SliTaz x86_64 with goal as SliTaz 4.0 x86_64.
But 4.0 x86_64 with same version is not realist, i decide to follow LFS 9.1 packages version.
For moment, i only base and dev stuff is ready, but because slitaz core packages as 4.0, not advantage of 5.0 (receipt v2, new tazpkg).
Maybe my way is wrong, i thinking realistic to first try to release fixed version.
Offline
Slitaz 4.0?
Why not 5.0? If I may ask...
Offline
The trail of the already builtin cross-compiling feature of cookutils has some disadvantages which is why I tend to shann's way, too.
Although I managed to build a working x86_64 cross-toolchain, it relies on not very recent parts (gcc 7.1, glibc 2.25, ...) and therefore was seen by me to be a short step in between.
The debugging of the scripts (killing my glibc while deleting the dependencies) and search for the way to solve inter-dependencies will have to be gone anyway.
So for the moment I somehow went back to the way shann seems to go to, by building a basic x86_64 systems (based on LFS 10 which is very recent) and then trying to include the necessary slitaz scripts to build up a new cooking toolchain (wok). I plan to use the most recent versions of the script, meaning to somehow orient on 5.0.
Then the debugging of the tazpkg receipts will have to follow.
shann has already done so for a good couple of packages, offered in his wok (thank you for that), but there will be a long way to go.
@guest_account: What puzzles me is your comment, that the discussion is getting too dev-focused. As far as I can see, many of us see the need for a x86_64 version of this lovely tiny distro. I am no developer either, but am willing to read manuals and tutorials (Linux from scratch being a lovely one to better understand linux anyway) and to invest my time to try figuring out how this could work.
I hope, there will be more like shann (and hopefully me, if my contributions could be seen as any help forward), bringing this to work.
Up to now, this somehow seems like some lonely soccer players in different corners of the field, sometimes playing very long passes across... but we would not be enough to form a winning team...
(and a coach would be helpful... ;-) )
I'll report, if there's any progress...
Offline
Hi Filou,
It's normal.
Infact work for x86_64 not really coordinated, alanyih first work on x86_64, Aleksej also and in few months me.
For the work to be beneficial, I think that indeed starting with branch 5.0 (rolling branch, because 5.0 not updated after 2018) and using LFS 10.0 is ideal.
I think we have to define our objectives well and share the work.
Offline
Hi shann,
fully agreed.
I propose that I try to figure out how I can populate the scripts into my basic LFS system to set up a running wok (maybe you already have some hints what failed for you with your current system?)
Although it's a little bit scary that other seem to have failed or just abandoned before us, this can't be an impossible task. I guess that there are almost no packages that don't already run on 64 bits on other distributions and most of Slitaz is shell script (which is why I love it) that doesn't have to be compiled and shouldn't care about 32 or 64 bits...
All is already running fine on a 64 bit Kernel (which would really have been a hard part).
So starting from Scratch (in the best sense of LFS) and taking over the working and proven parts of Slitaz should be no real magic (hope I am not too naive...).
So of course I will do my best and will be happy to coordinate our efforts!
À la prochaine et bonne nuit!
Offline
Hi Filou,
For my work, i started from alanyih stuff of x86_64, minimal base setup.
After bump version to gcc 8.2 (memory LFS 8.2), and after bump to LFS 9.1 build stack.
Infact, I encountered some issues with version upgrades, gcc 9.2 with glibc 2.31 which had to be patched to be able to compile, ncurses with the 5.x kernel branch. Readline 7 to 8 need rebuild and new chroot to use it.
In this case, i don't have LFS based (i have already build LFS to understood 8.2 and also 7.0 
).
Because SliTaz based on most shell script and busybox, it's easy to have "base".
64 bit Kernel can work on pure 64 bit mode or multilib, rolling use this mode to have 32 bit userland.
With your basic LFS system you can (not tested), install manually slitaz stuff (slitaz-base-config, tazpkg, slitaz-tools, cookutils). Maybe hard time.
I can be build iso with my wok to have x86_64 env available. Of course use slitaz 4.0 stuff (not receipt v2, and new tazpkg), but great to build 5.0 base x86_64.
Offline
Hi shann,
thanks for the information.
What I achived up to now is the following:
1.) I set up a LFS 10.0 base system following the LFS book up to incl. chapter 8
2.) Within the LFS system, I compiled busybox (incl. necessary patches) and put (only) the binary in /bin
3.) from outside the chroot I installed cookutils, sdft, slitaz-base-files, desktop-file-utils-extra on top of the LFS system
(using [c]tazpkg -gi {....} --root={LFS-dir} --nodeps[/c])
4.) I compiled advancecomp, lzma, p11-kit, make-ca, curl, openssh and git within LFS
5.) I cloned your wok
6.) I created symbolic links for wget, which and cpio to /bin/busybox inside the LFS
7.) I patched some of the slitaz scripts (/usr/bin/cook; /usr/libexec/cookutils/compressor) to meet the requirements for LFS lzma and other identified issues
With this setting, up to now I achieved a state-of-the-art environment which leads to the same results I saw within my adapted slitaz-cross-wok following LFS 7:
M4.tazpkg as a minimum result is cooked flawlessly (or at least it seems to me to be), while bigger packages with dependencies spoil my environment killing my glibc.
So now, I will step by step search for the remaining issues in the hope, that my wok will one day produce the packages we wish for...
Offline
Hi shann,
yes and now I have an idea, why.
You were absolutely right to point out the chroot environment which should protect the rest of the system.
When digging into the scripts I realized that the chroot is based on aufs and the scripts did not recognize that my 64bit 4.2.8 Kernel was built without aufs support (since it has to be built in manually and is not part of mainline).
So the scripts seemed to pretend that everything is on aufs, the rest protected and by that assumption simply killed my system.
So now, I am about to compile a 5.10.3 Kernel for my machine including aufs and then will try again.
... getting closer, I hope...
À la prochaine ...!
Offline
Offline
Hi shann,
nevermind, it's another step I had to learn on this long and steep way, but it's all about learning and understanding anyway, isn't it?
... the first attemps with a 5.10.3 Kernel (and below) failed; the leap from Slitaz's base of 3.x up there seems to be too large; the kernel is built perfectly within my LFS chroot, boots fine but produces memory allocation errors within Slitaz's 32 bit progs (especially libjavascriptcoregtk and libwebkitgtk for a start).
So to bridge this, I now compiled a 4.4.254 Kernel with aufs support and will try to step ahead with this within the LFS chroot.
I'll report...
Offline
... when I cooked ncurses, ncursesw was installed, throwing out lots of "wrong ELF format" and giving me another freezy shower, thinking everything was lost again...
but no: the lines saying "Leaving aufs chroot" and the still working environment proved, that the last step was successful...
So here I am now, with a (more or less) working wok based on binutils 2.35.1, gcc.10.2, Kernel 5.10.3 and glibc 2.32.
The first packages went through cooking successfully (m4, bison, db, zlib, ...).
For dependency loops I suggest to try tricking this "bridging environment" (it will be nothing more) by installing the necessary package the (B)LFS way and faking to have a tazpkg installed (this worked for ncurses, when I simply created a directory "ncursesw" in /var/lib/tazpkg/installed) and lead to a successful ncurses / ncurses-dev cook.
Since this simple trick didn't work for gmp/gmp-dev (they are checked within /sysroot/var/lib/tazpkg but within the pkg-list instead of the directories), I will have to check those...
... advancing slowly....
Offline
[ Generated in 0.018 seconds, 8 queries executed - Memory usage: 1.62 MiB (Peak: 1.77 MiB) ]
.