SliTaz Forum

Slitaz future?

(278 posts) (29 voices)

• Started 4 years ago by guest_account
• Latest reply from alanyih
• This topic is not resolved

Tags:

No tags yet.

1. 

   shann
   

   offline

   Administrator

   Hi Filou,

   Thanks for return, good job :).
   You have always problem with glibc killing environement inside new chroot LFS ?

   Posted 3 years ago #
2. 

   Filou
   

   offline

   Moderator

   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 ...!

   Posted 3 years ago #
3. 

   shann
   

   offline

   Administrator

   Hi Filou,

   Shit, i forgot to ask if you have aufs module kernel, i dont remember you have custom kernel.
   In my case, i check my cook file, and i comment try_aufs_chroot, but because i used vm don't broken host system.

   Posted 3 years ago #
4. 

   Filou
   

   offline

   Moderator

   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...

   Posted 3 years ago #
5. 

   Filou
   

   offline

   Moderator

   ... 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....

   Posted 3 years ago #
6. 

   shann
   

   offline

   Administrator

   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).

   Posted 3 years ago #
7. 

   Filou
   

   offline

   Moderator

   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...

   Posted 3 years ago #
8. 

   shann
   

   offline

   Administrator

   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 ?

   Posted 3 years ago #
9. 

   Filou
   

   offline

   Moderator

   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
   ./configure --prefix=/tmp && make && make install 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...!

   

   Attachments

   1. fail.jpg (187.7 KB, 471 downloads) 3 years old

   Posted 3 years ago #
10. 

    shann
    

    offline

    Administrator

    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

    Posted 3 years ago #
11. 

    Filou
    

    offline

    Moderator

    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...

    Posted 3 years ago #
12. 

    shann
    

    offline

    Administrator

    Hi Filou,

    you seem find root cause, non-shared-libs environment, but strange.

    Maybe i build rootfs with my devs stuff you can help to have SliTaz x64 native build env ?

    Posted 3 years ago #
13. 

    shann
    

    offline

    Administrator

    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 :)

    Posted 3 years ago #
14. 

    Filou
    

    offline

    Moderator

    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
    configure --prefix=/tmp --enable-shared --disable-static && make -j8 && make install
    it runs through fine, although the local libtool is called. The respective shared object files ARE created and filereturns:
    /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
    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...

    Posted 3 years ago #
15. 

    shann
    

    offline

    Administrator

    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 :)

    Posted 3 years ago #

RSS feed for this topic

Reply »

You must log in to post.