SliTaz Forum
You are not logged in.
Pages: 1
Hi there!
Some time (perhaps, a long time) ago I started to upgrade the SliTaz Toolchain. At that time, I have absolutely nothing happened.
This time I did it!
I use the latest Linux From Scratch handbook (LFS-7.10) to consult about packages versions and needed patches.
Work has recently started and has almost nothing to show. Today I have 61 packages in my wok and I add few more packages a day.
I started with a very small and stripped chroot: only SliTaz Toolchain and few additional packages (cacerts and libssl to download from https, and so on). No mercurial, no python, no Xorg... I want it to fine tune the build dependencies, and in order to do this I changed SETUP_PKGS in [c]chroot/etc/slitaz/cook.conf[/c].
I want to ask our oldest developers, Pascal Bellard or Christophe Lincoln, to help me:
[*]Please, set up the new Mercurial repository "wok-next" on the http://hg.slitaz.org/ with the default access permissions (like "wok" has) and let it be the copy of the "wok" at the beginning.
[*]Please, set up the fresh Rolling chroot at Tank and connect [c]conspy[/c] and web interface to it (like "wok", "wok-undigest", etc. connected).
After that I will make packages updates, we will be able to unite with all comers (open development! like in good old SliTaz days), people will be able to watch the process.
Now I want to stick with versions of the programs described in the LFS. Irregular updates can be fraught with unexplained bugs... Then we will be able to update the distribution more regularly.
And, it seems, is approaching the end of life of the current distribution, which is necessary to issue in appropriate way. Soon, we need to do is make cut and freeze the current Rolling, as was done for the "wok-stable" with all the current receipts, package repository and ISO images. In this I also ask the help of Pascal and Christophe.
Meet again! Do not go anywhere, it will be interesting! 
Offline
Hi Aleksej,
You can use http://hg.slitaz.org/wok-next/ and 'conspy -f 9' now.
FYI 'neuf' means both 'nine' and 'new' in french.
Offline
Thank you very much, Pascal!
PS. Web interface is available @ http://cook.slitaz.org/next/
Offline
Hi Pascal,
The problem exists somewhere in the cooker (/usr/bin/cook): chroot not update during the toolchain compilation.
For example, if I run "cook glibc" - it will make new package and then install it to the chroot. In other side, if package "glibc" will update by the "cook slitaz-toilchain" - the new package builded but not installed.
I'll try to find the problem tomorrow...
PS. I found the only one solution: to copy compile_rules() from the slitaz-toolchain package receipt to the separate script, and then to run it from the conspy chroot. I called the script "/make-toolchain". Hope this is the first and last time I need it for the current slitaz-next update.
Offline
Hi, SliTazers!
The LFS book is almost completely finished. The hardest part remained: Linux Kernel.
Troubles on the way:
The old glibc-related bug still here, and the solution is still:
Glibc cooked well when I started cooking directly on the Tank server in the [c]conspy[/c]:
[c]cook glibc[/c]
We should be careful updating glibc* receipts because automatic cooking the "glibc" and then "glibc-base" and then installing to the cooking chroot will "ruin the world": no one dynamically-linked binary will run.
I have a trick for this case: I rewrite the [c]/lib/ld-2.24.so[/c] (from outside the chroot) with the good file from the package glibc-base compiled on my host. And now we can proceed to manual rebuilding glibc & C° on the [c]conspy[/c] console.
PS. Found a cute Easter Egg Puppy
[c]make -f /home/slitaz/wok/linux/source/linux-4.9/drivers/lguest/Makefile Puppy[/c]
PPS. (Dec, 30):
Linux Kernel 4.9 was compiled on my host, but...
[*]Config seems outdated, too many "(NEW)" items. And this config looks interesting. Please, correct me, I have a little to none practice of the Kernel configuring. Maybe anyone knows a better Kernel config for the 4.9?
[*]Unable to compile 64-bit versioun using current (as well as updated) uclibc cross-compiler. It can't find something called rawcc, and when I added that folder with the rawcc to the path - it fail in other way. Currently only x86 Kernel compiled.
[*]Kernel compiled but packages not finished due to different paths. First, it finished both with: (a) $install/lib/modules/4.9-slitaz almost empty folder (broken symlink "build" and empty "modules.dep" inside), and (b) $install/lib/modules/4.9.0-slitaz full of stuff. Packages assumed modules in (a) and, of course, failed.
[*]Some paths changed also. For example, I read in the "linux" receipt, in the "install_module_headers()" function that it searched for "headers for lirc package" named "bt8xx, cpia2, cx25840..." under "drivers/media/video" folder. But, manual searching I found these under different folders and not sure these the same that means before (headers for lirc package): drivers/media/pci/bt8xx, drivers/media/usb/cpia2, drivers/media/i2c/cx25840... Now I assume they are the same as previously mentioned and planning to write simple search function.
[*]I believe I'll solve these problems, but sometimes later. Not only the Holidays now I want to finish some annual calculations and reports on my work. First two weeks of the January will be pretty busy...
--
Taking the opportunity I want to congratulate all a Happy New Year! Let your dreams come true.
Offline
Hi Aleksej,
good work until now - the Arch config is a good basic - I will help on that, as I did for 5.0 - Mid January will be perfect time for me......
Thomas
Offline
Aleksej,
Arch: PKGBUILD config config.x86_64 patch …
https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/linux
Happy New Year!
Offline
Fix:
Arch: PKGBUILD
https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/linux
Arch: PKGBUILD config config.x86_64 patch …
https://git.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/linux
Offline
Hi Thomas,
Your help will be very welcome, thank you.
Hi Alan,
Thank you for participating!
I mentioned that link in my previous post, sorry, I don't believe that patch will help in this situation.
Also, I just uploaded cooking logs to the tank server. You can see:
[*]cooking with the regular (outdated) "uclibc-cross-compiler-x86_64" package. Note too many errors: please, search in your web-browser for "Error: no such instruction:" phrase.
[*]cooking with the updated (latest) "uclibc-cross-compiler-x86_64" package. Please, scroll down to the very bottom, then scroll up a bit. Note error "rawcc: No such file or directory".
[*]here I symlinked rawcc to the /usr/bin/rawcc. Please, see at the very bottom: "rawcc: error trying to exec 'cc1': execvp: No such file or directory".
[*]here I symlinked also cc1. Please, see at the very bottom: "Fatal error: no compiled in support for x86_64".
-
Current fact: "uclibc-cross-compiler-x86_64" can't compile Linux Kernel for me, so I switched off creating x86_64 Kernel in the receipt for now.
I know, you have huge x86_64 SliTaz repository. Do you used "uclibc-cross-compiler-x86_64" or do you compiled using native x64 toolchain?
Offline
Hi Aleksej,
Config seems outdated, too many "(NEW)" items. And this config looks interesting.
Oops, you have same link.
uclibc-cross-compiler-x86_64-20160111.tazpkg
GCC / uClibc version?
Do you have try “normal cross-compile”, without cook/cooker and aufs ?
Latest News
15 May 2012, uClibc 0.9.33.2 Released
tux@slitaz:~$ uclibc-x86_64-gcc -v
Invoked as uclibc-x86_64-gcc
Reference path: /usr/share/uclibc-cross-compiler-x86_64/bin/..
arg[ 0] = rawcc
arg[ 1] = -U__nptl__
arg[ 2] = -v
Using built-in specs.
Target: x86_64-unknown-linux
Configured with: /home/landley/work/ab7/build/temp-x86_64/gcc-core/configure --target=x86_64-unknown-linux --prefix=/home/landley/work/ab7/build/cross-compiler-x86_64 --disable-multilib --disable-nls --enable-c99 --enable-long-long --enable-__cxa_atexit --enable-languages=c,c++ --disable-libstdcxx-pch --program-prefix=x86_64- --enable-threads=posix --enable-shared --build=x86_64-walrus-linux --host=x86_64-unknown-linux
Thread model: posix
gcc version 4.2.1
tux@slitaz:~$
----
cross-compile with glibc:
tux@slitaz:~$ uname -a
Linux slitaz 4.9.0-slitaz64 #1 SMP PREEMPT Mon Jan 2 11:37:34 UTC 2017 x86_64 GNU/Linux
tux@slitaz:~$ dmesg | grep gcc
[ 0.000000] Linux version 4.9.0-slitaz64 (root@slitaz) (gcc version 4.6.3 (SliTaz) ) #1 SMP PREEMPT Mon Jan 2 11:37:34 UTC 2017
tux@slitaz:~$ modinfo kvm
filename: /lib/modules/4.9.0-slitaz64/kernel/arch/x86/kvm/kvm.ko.gz
license: GPL
author: Qumranet
depends: irqbypass
intree: Y
vermagic: 4.9.0-slitaz64 SMP preempt mod_unload modversions
parm: allow_unsafe_assigned_interrupts:Enable device assignment on platforms without interrupt remapping support. (bool)
parm: ignore_msrs:bool
parm: min_timer_period_us:uint
parm: kvmclock_periodic_sync:bool
parm: tsc_tolerance_ppm:uint
parm: lapic_timer_advance_ns:uint
parm: vector_hashing:bool
parm: halt_poll_ns:uint
parm: halt_poll_ns_grow:uint
parm: halt_poll_ns_shrink:uint
tux@slitaz:~$
Offline
Do you used "uclibc-cross-compiler-x86_64" or do you compiled using native x64 toolchain?
Never used uclibc-cross-compiler-x86_64
1. slitaz-x86_64-2014 (glibc-2.13): cross-compile
http://forum.slitaz.org/topic/slitaz-50-release-date/page/2#post-29501
root@slitaz:~# uname -a
Linux slitaz 3.2.53-slitaz #1 SMP Wed Jan 1 18:22:13 UTC 2014 x86_64 GNU/Linux
[ 0.000000] Linux version 3.2.53-slitaz (root@slitaz) (gcc version 4.6.3 (SliTaz) ) #1 SMP Wed Jan 1 18:22:13 UTC 2014
root@slitaz:~# file /lib/libc-2.13.so
/lib/libc-2.13.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, stripped
2. slitaz-x86_64-2016 (glibc-2.19): native-compile
http://forum.slitaz.org/topic/slitaz-x86_64#post-43349
tux@slitaz:~$ uname -a
Linux slitaz 3.16.36-slitaz64 #2 SMP Mon Sep 12 07:26:30 UTC 2016 x86_64 GNU/Linux
tux@slitaz:~$ file /lib64/libc-2.19.so
/lib64/libc-2.19.so: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked (uses shared libs), for GNU/Linux 2.6.30, stripped
Compiled by GNU CC version 4.9.2.
Compiled on a Linux 3.16.36 system on 2016-09-08.
http://forum.slitaz.org/topic/slitaz-x86_64#post-43358
root@slitaz:/home/tux# gcc -v
Target: x86_64-slitaz-linux
--build=x86_64-slitaz-linux --host=x86_64-slitaz-linux
root@slitaz:/home/tux# cat /usr/share/doc/slitaz/toolchain.txt
SliTaz GNU/Linux toolchain
================================================================================
Build date : 2016-09-03
Architecture : x86_64
Build system : x86_64-slitaz-linux
Host system : x86_64-slitaz-linux
3. Docker-Tag
http://forum.slitaz.org/topic/slitaz-x86_64/page/2#post-43544
tux@slitaz:~$ docker run -it slitaz/slitaz-base:2.13
root@09ae98ea7ee0:/# /lib64/libc.so.6
GNU C Library stable release version 2.13, by Roland McGrath et al.
Compiled by GNU CC version 4.6.3.
Compiled on a Linux 3.2.14 system on 2013-12-28.
tux@slitaz:~$ docker run -it slitaz/slitaz-base:2.19
root@2b3c5287b346:/# /lib64/libc.so.6
GNU C Library (GNU libc) stable release version 2.19, by Roland McGrath et al.
Compiled by GNU CC version 4.9.2.
Compiled on a Linux 3.16.36 system on 2016-09-08.
Offline
Hi Alan,
Thank you for the answers. I understand now.
Offline
http://cook.slitaz.org/next/
Green 10%!
Small anniversary 
Offline
Yes it is good name:Slitaz «Next»
Sounds good and very original!
Offline
Do you know that SliTaz Next runs like a charme on UEFI computers?
Aleksej, you are a genius!
Offline
Hi Ceel,
Nice to hear it useful for you.
Unfortunately I have no one box with UEFI on board at my hands to develop/test/debug it. So, thank you, but reality is a bit different ☺
Offline
Pages: 1
[ Generated in 0.017 seconds, 7 queries executed - Memory usage: 1.57 MiB (Peak: 1.77 MiB) ]