SliTaz Forum
You are not logged in.
Hi Filou,
humm for ncursesw it's strange, normally ncurses doesn't have BUILD_DEPENDS. For wrong ELF Format, you need x64 kernel, i didn't encounter this type of error.
For gmp, BUILD_DEPENDS as binutils and m4.
For memory allocation errors, check limits with 'ulimit -a', infact need adjust data seg size to unlimited ('ulimit -d unlimited'), also check ulimit -m (for max memory size).
Offline
Hi shann,
I evaded some dependency problems by temporarily deleting the entries in BUILD_DEPs for those programs already provided by my LFS environment.
37 packages already went through fine:
advancecomp-2.1-x86_64.tazpkg
autoconf-2.69-x86_64.tazpkg
automake-1.16.2-x86_64.tazpkg
bash-5.0-x86_64.tazpkg
binutils-2.35-x86_64.tazpkg
bison-3.5.2-x86_64.tazpkg
bzip2-1.0.8-x86_64.tazpkg
bzip2-dev-1.0.8-x86_64.tazpkg
bzlib-1.0.8-x86_64.tazpkg
cacerts-20200709-x86_64.tazpkg
db-5.3.28-x86_64.tazpkg
db-dev-5.3.28-x86_64.tazpkg
dialog-1.3-20181107-x86_64.tazpkg
e2fsprogs-1.45.6-x86_64.tazpkg
elfkickers-3.1-x86_64.tazpkg
flex-2.6.4-x86_64.tazpkg
glibc-2.32-x86_64.tazpkg
glibc-base-2.32-x86_64.tazpkg
glibc-dev-2.32-x86_64.tazpkg
glibc-locale-2.32-x86_64.tazpkg
libtirpc-1.2.5-x86_64.tazpkg
linux-api-headers-5.10.3-x86_64.tazpkg
lzlib-4.57-x86_64.tazpkg
lzlib-dev-4.57-x86_64.tazpkg
lzma-4.57-x86_64.tazpkg
m4-1.4.18-x86_64.tazpkg
make-4.3-x86_64.tazpkg
ncurses-6.2-x86_64.tazpkg
ncurses-common-6.2-x86_64.tazpkg
ncurses-dev-6.2-x86_64.tazpkg
ncurses-extra-6.2-x86_64.tazpkg
patch-2.7.6-x86_64.tazpkg
perl-5.32.0-x86_64.tazpkg
perl-xml-parser-2.44-x86_64.tazpkg
tar-1.32-x86_64.tazpkg
zlib-1.2.11-x86_64.tazpkg
zlib-dev-1.2.11-x86_64.tazpkg
... will hunt for the others, too...
Some of the packages fail at the end of the compilation, saying that teh compiled libraries in .libs/ cannot be found. I will dig deeper for that one...
The ELF-format error arises, because tazpkg installs the dependencies from the slitaz repository, which is 32 bit. No wonder, it has the wrong format, because I have to build up one by one...
I don't see any memory allocation problems with the 4.4 kernel, but anything higher than 4.9 spits them out. Maybe some philosophy change the collides with the 32-bit libraries? Anyway, this should be sorted out with a switch-over to 64bit once we are done...
Offline
Hi Filou,
Great work 
.
Tazpkg catch from cooking by default for deps, you can skip them by :
- use AUTO_INSTALL_DEPS="no" to /etc/slitaz/tazpkg.conf
or
- define notexist url in /var/lib/tazpkg/mirror (that my choice, point to http://mirror.slitaz.org/packages/unstable/)
For memory allocation, maybe 4.9 is more strict or missing full 32bit library support.
In case mixed 32 libs inside x64 chroot LFS not good idea.
For libs cannot be found, can you have please example of output log ?
Offline
Salut,
since the installed deps-packages don't spoil my system anymore I see it rather as an information which packages are still missing, so I don't bother about them anymore.
Concerning the libs not to be found, I added an example for flex, the same error occurs (at least) for:
acl, attr, expat, gmp, libffi, libidn, libtirpc, liblzma, file, gawk, check, pcre and xz...
So there has to be something in the scripts which is buggy. Even more, when I perform a simple
[c]./configure --prefix=/tmp && make && make install[/c] in the flex source directory in the wok, the package compiles and installs without errors.
It has got something to do with libtools... ... digging .....
Bonne soirée...!
[attachment=49774,3061]
Offline
Hi,
infact, just inform that packages missing
hmm, in case you need to build libtool package and libltdl (dep for libtool), build deps as automake / autoconf.
i remember that need "bootstrap" few package to can skip circular deps aka "./configure && make && make install".
thanks, good evening also
Offline
Hi shann,
I'm suspecting another cause...
I compiled libtool into the LFS environment (although it seems to have been available to the chroot environment already, as libtool has only been called in the LFS environment after having been installed...
(what I mean is, if it hadn't already been available, libtool would not have been in the displayed lines...)
I can reproduce the error when I compile the same source code in the LFS environment with --disable-static and as far as I understood the libtool manuals, the .libs directory contains the PIC (position-independent code) that is necessary for the shared libraries.
Ergo: the wok (meaning: the cook command) tries to build shared-libs only packages but somehow my systems is identified as non-shared-libs environment (although ldconfig shows otherwise), leading to not compiled shared libs in the .libs directory that can't be used by libtool...
So I'll have to check why my system is treated as non-shared-libraries environment....
Good nite 2 all...
Offline
I push slitaz_x64.tar.gz with cook and toolchain stuff installed, also openssl and cacerts.
Inside /root/packages you have all 166 packages builded to installed deps if need.
Uncompressed 410Mo
Compressed 184Mo
Tarball contain slitaz_x64 folder as chroot env, need extract with root user to preserve fs permissions.
Upload in progress, after upload link as https://people.slitaz.org/~shann/slitaz64-stuff/slitaz_x64.tar.gz
EDIT: upload finished
Offline
Hi shann,
thank you for your kind support; as far as I can see, the cooking in your environment fails because of an unknown archiver interface (whatever that is...?!?)
I'll try to use your steps for my learning process but am not sure what will be the best way ahead...
I doubt that my environment really does not support shared libs. If I compile xz within the LFS environment (without "cook") from source with
[c]configure --prefix=/tmp --enable-shared --disable-static && make -j8 && make install[/c]
it runs through fine, although the local libtool is called. The respective shared object files ARE created and [c]file[/c]returns:
[c]/tmp/lib/liblzma.so.5.2.5: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, with debug_info, not stripped[/c]
which sounds fine to me so far (although I am not sure about the PIC-question).
This has to be a libtool secret. I will have to get a better understanding of libtool and where and with which parameters it is called during the cooking sequence. If I can compile the package manually, then why shouldn't it work with libtool with the correct parameters?
Maybe the scripts refer to some 32bit-only parameters that should be different for 64bits?!?
So I'll take my time trying to learn about libtool...
I have put my cooked packages on my Web.de webspace. If you'd like to check them, you'll find them here:
https://c.web.de/@337942326598965997/QhaNFMiJQhuEqY3q66F8Xg
Bash and perl for example installed fine within your environment and seemed to work at first glance...
Offline
Hi,
Shit, forgot to install lzma package, you can install them from packages directory.
I go to upload new tarball with package already installed, sorry for inconvenience.
Cook run several actions, build not static, remove debug_info, strip.
When i continue cook package, i see for php need that readline build in shared mode. Maybe one or several packages as non-shared and break others.
I go to check your packages
Offline
I am just about to add my LFS version to the mentioned webspace ("210204_LFS.tar.xz") with a xz-compressed size of 216MB. (EDIT: done!)
Since we use a different IP range, you'd have to copy your local /etc/resolv.conf to the LFS directory to be able to download additional stuff (like cloning your wok; since there is an SSL issue, you could enter [c]export GIT_SSL_NO_VERIFY=true[/c] so that it will be accepted (I know about the security issues, but this is only a bridge to 64bit Slitaz in a chroot... ;-) ))
So if you would like to fiddle around with it, feel free... ;-)
Offline
Thanks , upload new tarball in progress.
For git you don't need use GIT_SSL_NO_VERIFY=true 
Infact for git, it's doesn't use /etc/ssl/ca-bundle.crt, and just need to forced it to see inside.
Create ~/.gitconfig or update it with :
[c][http]
sslCAInfo = /etc/ssl/ca-bundle.crt[/c]
Also missing add readme for my chroot, you need add your /etc/resolv.conf inside .
Edit: Other tips for git command add in .gitconfig for command use less correcty without scroll
[c][core]
pager = less -F -X[/c]
Offline
... just cooked tcl, tcl-dev and sqlite (will add them to webspace) and found that unzip was not available.
When you play around with the chroot, remember that busybox is installed in /bin/busybox.
Adding the symbolic link to /usr/bin/unzip was enough to go ahead... !
Offline
I check-in after your message, /usr/bin/unzip exist and symlink in slitaz_x64 chroot.
Maybe on your chroot, i don't check them in this time.
EDIT: ok thanks for warning, i check in 210204_LFS.tar.xz, infact /usr/bin/unzip missing.
Offline
I am a fool....
... sometimes it's SOOOOO easy... >:-/
libtool was unsuccessful because the linker was not available as foreseen. I didn't see that immediately, because the configure script only gave back, that ld would not be GNU....
Creating a symbolic link from /usr/bin/ld to /usr/bin/x86_64-slitaz-linux-ld was enough!
The latest cooks ran through fine...
So let the cooking begin, I'll report as soon as I come to errors or will otherwise fill up my webspace with cooked x86_64 packages... !
Offline
Sorry to ask: but why are you not using GNU ld? Why is it named x86_64-slitaz-linux-ld? I do not have any concerns, I'm just curious.
Offline
Things need to be update for Slitaz.
1. Xorg (with at least glamor support)
2. Glibc
3. icu
4. libwebkit (to support newer CSS and html5)
Offline
@akm: in fact I AM using GNU ld, only the reported error message was about a non-GNU-ld, which pointed in the wrong direction.
I guess that the symbolic link was necessary because the whole toolchain uses the prefix x86_64-slitaz-linux- (I took over the triplet that is used in x86 slitaz) and therefore libtool looked for the "included" ld...
@mistfire:
In order to be able to switch over to x86_64 ALL PACKAGES will have to be rebuilt.
I hope that your short and snappy post was not meant as sort of "purchase order", 'cause if you read through this thread, it seems that shann and me are the only ones investing our time for this endeavour at the moment.
So when you identified the need for new packages, I'd suggest that you download the latest LFS-wok I created and try to support us.
It's still a long way to go, all we achieved up to now is a seemingly working x86_64 wok with almost the latest toolchain in a "Linux from Scratch" environment enriched with the wok scripts and from there, some 50 packages as a start.
We WILL meet packages with errors we will have to resolve, so there's still lots of work to do.
Your helping hand would be more than welcome, please don't just stand by, point to specific packages you would like to have first and wait for others to do the work...
(sorry if I am writing too frankly... I don't mean to offend...)
Offline
I really have neither much time nor skill, so I don't think I can be too much help, but I have a couple questions:
1. Do I have to build Linux from Scratch (I'm not very good with Linux) and is it that
hard for someone who knows the commands cd (change directory) ls (list contents) and
basic vi (which isn't that hard ) Will I come across things requiring deeper knowledge?
Or will it just need a bootloader? Or chroot? (Still, would chroot or a bootloader be easy to handle?)
2. I don't know how to test programs. Is that very time-consuming?
3. Is gmake that hard? Is it the only requirement to help?
4. What is a wok exactly? Is it a group of programs (their binaries or sources? or
both?) in development? does the kernel count as part of the wok?
5. You don't use make (a utility to build programs or applications I guess) to install
your programs, but instead try authoring "control files" (I guess?) as well as
preinstallation (before installation) and postinstallation (after installation) scripts,
which help the package manager handle the installation, right?
I might have used many words, but that's because I want to make it understandable for
the dear reader;D
Offline
Don't mind for the questions (although some of them might be easily answered by some DuckDuckGo/Starpage/Google queries...)...
1. The 210205_LFS-wok.tar.xz I pushed to my webspace (for the link look at one of the previous posts) is the RESULT of my compiling as LFS describes. So no, you don't HAVE to do it all yourself. But I recommend going through the procedure one time or another, because LFS describes quite clearly, how a linux system is set up and what the commands mean. Therefore, to gain a better understandig of what linux is about and how it is set up, LFS is a very good compilation.
2. The testing is fast, but finding the errors and resolving them takes time. Sometimes LOTS of time...
3. if by gmake you mean GNU make, it depends. Most programs are quite straightforward, as you just have to type [c]./configure && make && make install[/c] and the Makefile scans your system and makes all the necessary adjustments (as long as you have the necessary dependencies already installed). But the make system wouldn't really be the place to go for you. -> 4.
4. The wok (or better the cookutils) is a system of scripts the genius founding fathers of Slitaz figured out to almost automatically produce ready-to-go packages (-> .tazpkg).
As detailed in the "Cookbook" (to be found on the Slitaz Documentation page), for every package there is a "recipe" to be found that provides the details for the package: where the sources can be downloaded from, how it is compiled, which parts will have to be packed into which subpackage (for example readline and readline-dev or look at the util-linux subpackages...).
So when your system is setup with a local wok (which is as easy as [c]tazpkg -gi cookutils && cook setup-wok[/c] ) then you should be ready to cook packages with a simple [c]cook <package>[/c] command.
So far the theory; with the LFS-wok I have built, there should be an already working x86_64 wok.
After unpacking ([c]tar xz 210205_LFS-wok.tar.xz[/c] ) you can enter the environment with the provided "chroot" script (you are then enclosed in a chroot prison, that can't harm your host system, since the only way out is typing "exit". The chroot can't access your outer host file system.
What you need are the recipes in the wok, shann has provided a link to his x86_64 wok somewhere in the other "Slitaz future" thread.
With the recipes, you may start to cook packages by typing "cook <pkg>" and could support by testing, which packages build fine and where you encounter errors (and which ones). As soon as the wok proves to be stable and the recipes entail all the Slitaz-cooking packages, there will be a lot to do.
5. should be answered by 4., since the task at hand is to build x86_64 packages to set up a 64bit-version of Slitaz...
I hope I could be of any help and didn't puzzle you even more...
Offline
Alright... should one use debian or SliTaz as the host system? Forgot to ask about that... And I'm also curious whether one needs a separate partition to work on it. It seems like it is worked on not in a separate partition, but a simple subdirectory (or a folder if you would rather call it that way).
Offline
The host system doesn't really matter, it's only important that your kernel supports aufs. (I hope that the aufs tools support any kernel, not just the 4.4.254 that I compiled)
You don't need any extra partition, in fact I use Slitaz and unpack the folder into RAM (my Laptop has 16 GB RAM which makes a 64bit Kernel obligatory). If it fails unrecoverably, I just exit and delete it, otherwise I repack it and push the result back to my HD.
Offline
After the first packages went through quite well on the basis of shann's wok, I started over again using Christophe Lincoln's SliTaz Cooking wok available in the Slitaz Mercurial Repos (http://hg.slitaz.org/).
Since LFS configures GCC to use /lib instead of /lib64 for x86_64 systems (see step 5.3, 6.18 and 8.26 on http://www.linuxfromscratch.org/lfs/view/stable/), many receipts from this wok compile fine as well after adding "x86_64" to the HOST_ARCH variable. A check, if newer versions of the package sources are available are helpful as well as the deletion of old patches.
When the package fails, a closer look at LFS compilation configs might be of help.
Happy cooking!
Offline
Uhhhh... so you uploaded everything important to your webspace again? And you started from scratch, replacing Shann's receipts that make usable binaries out of the source code and the supplied makefiles and files named ./configure with the ones Christophe Lincoln (don't we call him Pankso?) made. Because Shann used experimental receipts made (or at least used) by Alanyih that makes things easier, right? Because Pankso's cooking wok is the more standard codebase for SliTaz, that I actually found to be maintained. Also, "cooking wok" has something to do with cookutils this time, but only in that it is a group of receipts for cooking all kinds of usable programs patched and maintained.
Offline
@akm:
Well ... in general: yes.
1.) shann's wok was a starting point for me in order to test my created wok. I was convinced that shann's receipts - already customized to x86_64 - were better than to use i486 scripts to start testing.
2.) During the testing I found that the cooking sometimes failed for libraries that were searched in /lib64 - according to the receipts - but were not built there. It took some time for me te remember the information in LFS's steps as mentioned in my previous post. Therefore, the "original" receipts that are configured for the libraries to be in /lib instead of in /lib64 were even better suited due to the configuration that LFS introduced.
3.) While experimenting with Pankso's wok, I found out that for many packages (I started alphabetically and went through to "D" now, with a good load of errors I'll explain in a minute) I just had to add "x86_64" to the HOST_ARCH variable and the cooking went through fine (as far as I can judge up to now. When extracting, it seems that the necessary files are contained and [c]file[/c] gives back, that ELF64 packages have been built...). For a start, I added this quite bluntly by a simple
[c]find . -type f -name receipt -exec sed -i 's|HOST_ARCH=\"|HOST_ARCH=\"x86_64 |' {} \;[/c]
(knowing that it might be doubled or create other problems later, but this is a START into a working x86_64 SliTaz, not the finetuning... !)
4.) While shann seems to have invested a good amount of time, there are only 167 package receipts in his wok up to now. When looking at Pankso's wok, we speak about 5694 packages. So if we want to go to a running and complete SliTaz, I guess the path to follow should be quite clear.
---------------------------------------
Up to now, my wok is able to create (what I would call "first level") packages, meaning all those that only show dependencies already available in the LFS environment.
When needing more than that, many packages fail to find the respective include-libraries although the correct tazpkg-dev had been installed to the chroot. So I have to fiddle around some more to find out why either the packages are NOT installed though they are mentioned during the cooking process OR are installed but the library folder is not included in the library path. (or any other option I haven't figured out yet...)
At this moment, I am uploading the 227 packages that have already been built according to Pankso's receipts and the latest version of my LFS wok for those who would like to contribute or play around by themselves.
I'll continue to build the "first level packages" and to try to figure out what's wrong with the dependency-libs...
Offline
[ Generated in 0.017 seconds, 8 queries executed - Memory usage: 1.6 MiB (Peak: 1.77 MiB) ]