(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...)
Slitaz future?
(278 posts) (29 voices)- Started 4 years ago by guest_account
- Latest reply from alanyih
- This topic is not resolved
-
shann
offlineAdministratorFilou,
Normally cook packages run inside chroot env with aufs to protect system against modifications.
It's strange that your bison build broken host system.Posted 4 years ago # -
Filou
offlineModeratorI 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:
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 =========================================Checking the m4 binary reports:
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 strippedso,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):
awk: cmd. line:9: warning: regexp escape sequence '\"' is not a known regexp operator
till it says "Done, Time: 17.70s. Size: 666986 B -> 610823 B. Save: 55 KB."After that,
/usr/libexec/tazpkg/remove: line 116: busybox: not found,
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...
Posted 4 years ago # -
mojo
offlineKey MasterI 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.Posted 4 years ago # -
Filou
offlineModeratorCommenting out line 544 in remove_deps() subroutine, which is
echo 'y' | tazpkg remove $dep --root=$root >/dev/null
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...
Posted 4 years ago # -
guest_account
offlineMember@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.
Posted 4 years ago # -
shann
offlineAdministratorHi 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.
Posted 4 years ago # -
shann
offlineAdministratorOf course, when i begin use 4.0, 5.0 go to rolling release model.
Follow 5.0 base maybe instead best choice.Posted 4 years ago # -
Filou
offlineModeratorThe 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...
Posted 4 years ago # -
shann
offlineAdministratorHi 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.
Posted 4 years ago # -
Filou
offlineModeratorHi 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!
Posted 4 years ago # -
shann
offlineAdministratorHi 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.
Posted 4 years ago # -
Filou
offlineModeratorHi 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
(usingtazpkg -gi {....} --root={LFS-dir} --nodeps)
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 issuesWith 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...
Posted 4 years ago #
Reply »
You must log in to post.
