SliTaz Forum

Slitaz on armel?

(58 posts) (5 voices)

• Started 10 years ago by pirandr
• Latest reply from alanyih
• This topic is not a support question

Tags:

No tags yet.

1. 

   pirandr
   

   offline

   Member

   Sorry for the slow replies (but its likely the speed at which I can work...). Compilation takes time and mistake are a bit more costly time-wise (but I don't mind :) ).

   @alanyih: I never answered some of your earlier questions/replies so let me do that now which things compiling in the background.

   1. Regarding Raspbian

   IMHO Raspbian is the best option for the Raspberry Pi.

   I certainly agree that it is much easier to get started there and there's quite a bit of documentation for Raspbian. However, I found that Raspbian was running rather slowly on my Raspberry Pi. I don't think such slow speed is justified. I ran a computer with similar specs for many years (well, with the possible exception of the GPU but that's because we don't understand the Raspberry GPU very well) and it was fast.

   I was running gnome, gdm, firefox with no slowdown. The only "secret" is that I used an older distribution.

   However, with Debian variants, I cannot go back too far in the past since ARM was not yet supported. So I cannot even test my hypothesis (that using some well chosen old versions of software will give me the speed gain I seek).

   But SliTaz has a fairly strong anti-bloat policy. I've been keeping in my pocket as a backup system for years now. And I love it. I was originally drawn by its boot speed. But now I realise taht I like how you can choose which large programs you want to use and which ones you do. I like the fact that (almost?) all tools are script so they are portable and its possible to easily understand what's going on (and customize them easily without too much trouble). My biggest gripe was that I couldn't get my wireless card working but this is no longer an issue in 4.0.

   So that's why I tried to move from Raspbian to SliTaz.

   2. Toolchain history

   Thanks for clarifying that. Now I know you were talking about the dates that the cross-compilation tools were released.

   Although as you may deduce from 1., I don't think that newer is always necessarily better. (But I'm still very happy you pointed out this fact.) Although I was not able to find a slitaz-arm-toolchain-20140212.tar.bz2 anywhere. I was mentioned in this post.

   4. SliTaz arm:
   slitaz-arm-toolchain-20120519.tar.bz2 *
   slitaz-arm-toolchain-20120529.tar.bz2 **
   slitaz-arm-toolchain-20140212.tar.bz2 ***
   32 bit softfp toolchain:gcc-4.6.3
   eglibc-2.13

   3. glibc-base receipts and files

   Thanks! Although that was already in the mirror I got from sat. I guess what I mean is that I was trying to get a working native copy of gcc and dependencies.

   4. TightVNC and qt

   I don't quite understand why we started talking about this already. I haven't gotten a compile xserver at the moment! Maybe you are just looking one step ahead?

   Posted 10 years ago #
2. 

   pirandr
   

   offline

   Member

   @pankso: I'm so very glad that you are joining this conversation.

   Can you summarize the state of advancement? Or is the arm repo representative of it?

   And could you confirm that the arm repo is indeed armel (and not armhf)?

   From the updated ARM repo (thanks for that!), it looks like there are some packages for Xorg (but no xorg-server). Does this mean there is a working copy of X now? Or not quite.

   I did NOT try native compilation with qemu-arm-static but it may be easier to build SliTaz ARM, so I will investigate.

   I see a gcc-lib-base but no gcc. I guess there's no binary yet? I thought that godane's tool is supposed to yield a native gcc binary. (It requires a cross compiler so it can give another cross-compiler, right?)

   @pirandr slitaz-arm/sat is just a small tool to generate an ARM distro using precompiled packages, but you dont need to put all mirrored packages into packages/.

   Thanks for the clarification! Although I did want as much as possible since it was fairly small even then (and I didn't want to spend the time accidentally compile a package that was already available; there's enough unavailable ones to make!)

   Posted 10 years ago #
3. 

   pirandr
   

   offline

   Member

   Ok, so I went ahead with a clean cross-compile environment (since native compilation doesn't seem to be quite there yet).

   # tazdev gen-chroot --arch=arm
   # tazdev chroot --arch=arm
   # wget http://mirror.slitaz.org/packages/cross/
   # tar xjf slitaz-cross-arm-toolchain*.tar.bz2
   # cat slitaz-cross-arm-toolchain*/README

   Then setup the cook env with 'cook arm-setup && cook setup --wok' to get the cooking wok in /home/slitaz/wok of the chroot. After that you can cook packages. Cook will not build packages if HOST_ARCH is not set in the receipt, this is done because we use the same wok for all arch.

   For those following, that wget line actually requires look into the directory and downloading the only file in there

   # wget http://mirror.slitaz.org/packages/cross/

   and the export in slitaz-cross-arm-toolchain*/README should be

   export PATH=$PATH:/usr/cross/bin

   instead of

   export PATH=$PATH:/usr/cross

   There seemed to be some other path issues with this version of cross to which I just applied some hacky fix

   <br />
   $ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/cross/i686-pc-linux-gnu/arm-slitaz-linux-gnueabi/lib/<br />
   $ ln -s /usr/cross arm<br />

   I cooked m4 just to test and it worked fine. But couldn't get xz to cook. This error is probably what's stopping configure right now:

   arm-slitaz-linux-gnueabi-gcc: error: unrecognized option '-qlanglvl=extc99'

   Edit:

   I will soon get an Raspberry Pi so I will be able to improve SliTaz support for it. That said I would be very happy to get help and people involved in the Slitaz ARM port.

   I guess this should have been one of the first things for me to test but I just tried the all-packages sat generated version on the Raspberry Pi and it boots without issue (I did try alanyih's armhf image a long time ago and that worked too).

   Posted 10 years ago #
4. 

   pirandr
   

   offline

   Member

   I thought that godane's tool is supposed to yield a native gcc binary. (It requires a cross compiler so it can give another cross-compiler, right?)

   Well, I answered my own question there. The /cross in WORK=/cross of cross.conf was the target directory, not the source so this does indeed build a cross-compilation tool.

   Still, even the arm-slitaz-linux-gnueabi-gcc built from my-cookutil gives a unrecognized option '-qlanglvl=extc99' error. (I got binutil and gcc-static to build this way, but not the rest.)

   Posted 10 years ago #
5. 

   alanyih
   

   offline

   Administrator

   slitaz-arm-toolchain-20120519.tar.bz2 *
   slitaz-arm-toolchain-20120529.tar.bz2 **
   slitaz-arm-toolchain-20140212.tar.bz2 ***

   slitaz-arm-toolchain-armhf-20120630.tar.bz2

   http://forum.slitaz.org/topic/chroot/page/3#post-27117

   ># wget http://mirror.slitaz.org/packages/cross/

   SliTaz uses the sysroot method

   1. cross howto
   tux@slitaz:~$ cross howto | head

   SYNOPSIS
   cross [command|package] package

   DESCRIPTION
   Cross is a tool to build a cross toolchain on SliTaz GNU/Linux. The
   ARM platform is actually supported and a x86_64 toolchain is on the
   stove

   COMMANDS

   2. Cross - Help build a cross toolchain on SliTaz.
   cookutils changeset 361:e7e7979eb49d
   http://hg.slitaz.org/cookutils/rev/e7e7979eb49d

   Add cross (let have a cross toolchain builder)
   author Christophe Lincoln <pankso@slitaz.org>
   date Wed May 09 22:15:39 2012 +0200 (21 months ago ago)
   [..]

   diff -r c75f13234af0 -r e7e7979eb49d cross
   --- /dev/null Thu Jan 01 00:00:00 1970 +0000
   +++ b/cross Wed May 09 22:15:39 2012 +0200
   @@ -0,0 +1,272 @@
   +#!/bin/sh
   +#
   +# Cross - Help build a cross toolchain on SliTaz.
   +#
   +# Copyright 2012 (C) SliTaz GNU/Linux - BSD License
   +# Author: Christophe Lincoln <pankso@slitaz.org>

   3. Create a prebuilt cross toolchain tarball.
   http://hg.slitaz.org/cookutils/file/3f5c9e87f05d/cross

   448 gen-prebuilt)
   449 # Create a prebuilt cross toolchain tarball.
   450 init_compile
   451 date=$(date "+%Y%m%d")
   452 package="slitaz-$ARCH-toolchain-$date"
   453 tarball="$package.tar.bz2"

   4. SliTaz uses the sysroot method
   ( 1). cook.conf
   http://hg.slitaz.org/cookutils/file/3f5c9e87f05d/cook.conf

   51 # SliTaz uses the sysroot method, this tells GCC to consider dir as the root
   52 # of a tree that contains a (subset of) the root filesystem of the target
   53 # operating system. Target system headers, libraries and run-time object
   54 # files will be searched in there. Cook will use the tools and sysroot in
   55 # the CROSS_TREE for cross compiling. Example: CROSS_TREE="/cross/$ARCH"

   (2) .Cook log
   http://cook.slitaz.org/cross/arm/cooker.cgi?pkg=linux

   Cook: linux 3.2.53
   ================================================================================
   arm sysroot: /cross/arm/sysroot
   Adding /cross/arm/tools/bin to PATH
   Using cross-tools: arm-slitaz-linux-gnueabi-
   QA: checking package receipt...
   QA: unable to reach: http://www.kernel.org/
   Checking build dependencies...
   Using packages DB: /cross/arm/sysroot/var/lib/tazpkg
   Extracting: linux-3.2.53.tar.xz
   Executing: compile_rules
   CFLAGS : -march=armv6 -O2
   Compiling: arm Kernel

   (3). slitaz-arm-toolchain-20120519.tar.bz2 * (deprecated)
   http://mirror.slitaz.org/packages/cross/slitaz-cross-arm-toolchain-20120519.tar.bz2

   --prefix=/usr/cross/arm --libexec=/usr/cross/arm/lib

   (4).
   slitaz-arm-toolchain-20120529.tar.bz2 **
   slitaz-arm-toolchain-20140212.tar.bz2 ***
   slitaz-arm-toolchain-armhf-20120630.tar.bz2

   --prefix=/cross/arm/tools --libexec=/cross/arm/tools/lib --sysroot=/cross/arm/sysroot

   Posted 10 years ago #
6. 

   alanyih
   

   offline

   Administrator

   2b. Can you post a full cook.conf for this? The cook.conf from arm.balinor.net/slitaz/armhf/ seems to be only for cross-compilation.

   1. Fixed. Thanks.
   http://arm.balinor.net/slitaz/armhf/packages/cookutils-2.0-armhf.tazpkg

   # Target host architecture type (Glibc doesn't support i386 anymore).
   ARCH="arm"

   2. SliTaz arm
   2013-03-25 15:24 : cookutils-3.1.4-arm.tazpkg

   cookutils-3.2-arm.tazpkg 2014-Feb-18 23:46:38
   http://cook.slitaz.org/cross/arm/packages/cookutils-3.2-arm.tazpkg

   cook.conf
   http://cook.slitaz.org/cross/arm/cooker.cgi?download=../wok/cookutils/taz/cookutils-3.2/fs/etc/slitaz/cook.conf

   # Target host architecture type (Glibc doesn't support i386 anymore).
   ARCH="i486"

   Posted 10 years ago #
7. 

   alanyih
   

   offline

   Administrator

   3. Distro Super Test – Raspberry Pi Edition
   http://www.linuxuser.co.uk/reviews/distro-super-test-pi-edition

   SliTaz 4
   A tiny distro supposedly for use on desktop and on server

   Overall Score
   4/10

   SliTaz has a place as a very fast web server, but that is unfortunately all it can do without serious work

   >So that's why I tried to move from Raspbian to SliTaz.

   Have any idea?

   SliTaz 4
   A tiny distro supposedly for use on desktop and on server

   With the smallest image in the test, SliTaz is quick to download, install and boot. In fact, it shows off on startup that it took only three seconds to get to the command line – the fastest in this test. SliTaz is in its fourth version, released in the middle of last year. As an independent distro, not based on anything else, it is one of the genuine few that support hard float operations without being based on Raspbian. Clocking in at only 500MB on the SD card, it’s certainly a feat to have this fully working system on the Pi.

   That low storage footprint comes at a price, though: there isn’t much to SliTaz. Coming with a grand total of 17 packages pre-installed, it’s an incredibly lightweight system that the developers themselves admit is meant to eke the max out of the Pi. The problem is, while the full SliTaz repos have a decent selection of packages, the Pi version only has 268. These are mostly utilities, and you can’t install a desktop environment from the repos. However, there is access to Xorg, and all the tools needed to compile it yourself. SliTaz has its own package manager, tazpkg, with a good search function to find what packages are available in lieu of a graphical manager. While you can also search the website for packages, you can’t filter by what’s available on Pi or not.

   SliTaz on Pi then is very focused on being used as some kind of headless server, and admittedly thanks to the lack of packages it is fast, and it will draw very little power. The problem is, something like Arch is basically as fast, and the repositories are full of software that will allow you to also make it into a server. Also, you can also very easily turn Arch into a desktop system, something that SliTaz is very noticeably lacking.

   SliTaz definitely has its place, and as a server it is quick to set up and has a lower footprint than the others. It just lacks the flexibility inherent in the Raspberry Pi itself.
   Overall Score

   4/10

   SliTaz has a place as a very fast web server, but that is unfortunately all it can do without serious work

   Posted 10 years ago #
8. 

   pirandr
   

   offline

   Member

   Now that I've fixed my misunderstanding of what cross does (despite being told this many time! Sorry about that.), I can finally make sense of this.

   Still, no-one has posted a newer version of the prebuilt toolchain so for the moment I'm still on

   http://mirror.slitaz.org/packages/cross/slitaz-cross-arm-toolchain-20120519.tar.bz2

   Can someone gen-prebuild on the cooker and post the package from there? If nobody does and I'm successful, I'll post my prebuild, of course.

   Although the half build I did manage to make (which should be an up-to-date version, I think) didn't seem to make much of a difference for cooking (at least I wasn't able to build all the packages that the cooker at http://cook.slitaz.org/cross/arm/ is able to) and that seems rather odd to me.

   I'm going to try a full build from the chrooted system this time just to make sure.

   Although I wish the tool wouldn't clobber everything and start over every time there's an error (and just continue from the last configure/make line).

   1. Fixed. Thanks.
   http://arm.balinor.net/slitaz/armhf/packages/cookutils-2.0-armhf.tazpkg

   # Target host architecture type (Glibc doesn't support i386 anymore).
   ARCH="arm"

   2. SliTaz arm
   2013-03-25 15:24 : cookutils-3.1.4-arm.tazpkg

   cookutils-3.2-arm.tazpkg 2014-Feb-18 23:46:38
   http://cook.slitaz.org/cross/arm/packages/cookutils-3.2-arm.tazpkg

   cook.conf
   http://cook.slitaz.org/cross/arm/cooker.cgi?download=../wok/cookutils/taz/cookutils-3.2/fs/etc/slitaz/cook.conf

   # Target host architecture type (Glibc doesn't support i386 anymore).
   ARCH="i486"

   Thanks for posting this! Sadly, I now realised there isn't a native gcc (and other build tools) anywhere

   >So that's why I tried to move from Raspbian to SliTaz.

   Have any idea?

   I'm not sure what you mean. Do you mean

   - "Any idea why SliTaz is rated so low?" (The main concern seems to be the availability of programs.)
   - "Any idea how to fix the problems mentioned here?" (Well, make more packages available, I guess...)
   - "Any idea how to make more things available?" (Well, I guess that's what we are doing now. Hopefully, I can just focus on where you all got stuck last time and don't have to redo too much of what's already known to get there.)

   Posted 10 years ago #
9. 

   pirandr
   

   offline

   Member

   So I've finally build the cross compilation tool from cross (the one included in cookutils this time).

   A quick note:

   On arm, eglibc compilation is run as part of cross compile and cross eglibc is a possible but it is not documented in usage for cross.

   This is probably something you all already have but here's the result

   https://github.com/pirandr/slitaz-arm

   I also put the eglibc source there so that its possible to build the cross compilation tools without svn (by manually copying those archives to /home/slitaz/src). Of course, this will only work until versions change.

   And so I went on to try and build xz this time and it worked again. Looking at the online cooker, it looks like you were trying to build libxslt so I though I might give it a try. I went ahead and built

   libxml2 libxml2-dev zlib zlib-dev

   And then ran

   cook libxslt

   I see
   

   <br />
   root@hostname:/home/slitaz# cook libxslt</p>
   <p>Cook: libxslt 1.1.26<br />
   ================================================================================<br />
   arm sysroot: /cross/arm/sysroot<br />
   Adding /cross/arm/tools/bin to PATH<br />
   Using cross-tools: arm-slitaz-linux-gnueabi-<br />
   QA: checking package receipt...<br />
   Checking build dependencies...<br />
   Using packages DB: /cross/arm/sysroot/var/lib/tazpkg<br />
   Installing dep (pkg/local): libxml2-dev-2.8.0-arm.tazpkg<br />
   Connecting to mirror.slitaz.org (46.105.127.17:80)<br />
   zlib-1.2.8.tazpkg    100% |*******************************| 35924   0:00:00 ETA<br />
   Connecting to mirror.slitaz.org (46.105.127.17:80)<br />
   glibc-base-2.14.1.ta 100% |*******************************|  1270k  0:00:00 ETA<br />
   Installing dep (pkg/local): libxml2-2.8.0-arm.tazpkg<br />
   Connecting to xmlsoft.org (176.31.99.103:21)<br />
   libxslt-1.1.26.tar.g 100% |*******************************|  3321k  0:00:00 ETA<br />
   Extracting: libxslt-1.1.26.tar.gz<br />
   Executing: compile_rules<br />
   CFLAGS   : -march=armv6 -O2<br />
   configure: loading site script /etc/slitaz/cook.site<br />
   checking build system type... i486-slitaz-linux-gnu<br />
   checking host system type... arm-slitaz-linux-gnueabi<br />
   checking for arm-slitaz-linux-gnueabi-gcc... arm-slitaz-linux-gnueabi-gcc<br />
   checking for C compiler default output file name...<br />
   configure: error: in

   /home/slitaz/wok/libxslt/source/libxslt-1.1.26':
   configure: error: C compiler cannot create executables
   See `config.log' for more details.<br />
   Build dependencies to remove: 6<br />
   Removing: glibc-base/usr/bin/tazpkg: line 139: dirname: not found<br />
   /usr/bin/tazpkg: line 139: dirname: not found<br />
   `

   before an avalanche of errors. tazpkg: not found That can't be right. I try to run it and indeed its not there anymore. I get out of the chrooted environment but can't go back in!

   chroot: can't execute '/bin/sh': No such file or directory

   Bullshit! /bin/sh is there and I can certainly run it directly from the outer system. I suspect that glibc of the chrooted system got removed (as the last lines suggest) instead of glibc in /cross/arm/sysroot.

   Edit: And here's the kicker, the configuration error was
   
/cross/arm/tools/lib/gcc/arm-slitaz-linux-gnueabi/4.6.3/../../../../arm-slitaz-
linux-gnueabi/bin/ld: skipping incompatible /cross/arm/sysroot/lib/libc.so.6 wh
en searching for /lib/libc.so.6
/cross/arm/tools/lib/gcc/arm-slitaz-linux-gnueabi/4.6.3/../../../../arm-slitaz-
linux-gnueabi/bin/ld: cannot find /lib/libc.so.6 inside /cross/arm/sysroot


   That's right, it couldn't find libc!

   Posted 10 years ago #
10. 

    pirandr
    

    offline

    Member

    I also just noticed that when I ran cook arm-setup, I got the warning

    WARNING: (e)glibc-base is not installed in sysroot

    But I think eglibc is installed in /cross/arm/sysroot. Its just that there's not receipt at /cross/arm/sysroot/var/lib/tazpkg/installed/glibc-base/receipt (obviously since it wasn't installed by tazpkg). However, I'm thinking this is still confusing cook and its trying to install another glibc from mirror.slitaz.org when it can't find one?

    I use Eglibc with cross to build the ARM cross toolchain and used the glibc-base package to provide libc in ARM.

    How do I "use" the glibc-base package in this way? (How do I tell arm-setup that this is what it should do?)

    Posted 10 years ago #
11. 

    alanyih
    

    offline

    Administrator

    But I think eglibc is installed in /cross/arm/sysroot.

    How do I "use" the glibc-base package in this way? (How do I tell arm-setup

    install
    file:///usr/share/doc/tazpkg/tazpkg.en.html

    specify the root system where you want to install the packages via the --root= option:

    # tazpkg install path/to/package-1.0.tazpkg --root=/mnt/rootfs

    Posted 10 years ago #
12. 

    alanyih
    

    offline

    Administrator

    Checking build dependencies...
    Using packages DB: /cross/arm/sysroot/var/lib/tazpkg
    Installing dep (pkg/local): libxml2-dev-2.8.0-arm.tazpkg
    Connecting to mirror.slitaz.org (46.105.127.17:80)
    zlib-1.2.8.tazpkg 100% |*******************************| 35924 0:00:00 ETA
    Connecting to mirror.slitaz.org (46.105.127.17:80)
    glibc-base-2.14.1.ta 100% |*******************************| 1270k 0:00:00 ETA
    Installing dep (pkg/local): libxml2-2.8.0-arm.tazpkg

    setup-mirror|-sm Change the mirror url configuration.

    # tazpkg setup-mirror (IN chroot)

    http://cook.slitaz.org/cross/arm/packages/

    Or path/to/your_arm_packages

    Posted 10 years ago #
13. 

    pirandr
    

    offline

    Member

    Thanks! Downloading and installing glibc-base with tazpkg --root= fixed my chrooted system. Although its still removes glibc-base every time I cook anything (successfully or not). This is even with a package that should normally work (and without any downloads from the mirror).

    
Cook: ncurses 5.9
================================================================================
arm sysroot: /cross/arm/sysroot
Adding /cross/arm/tools/bin to PATH
Using cross-tools: arm-slitaz-linux-gnueabi-
QA: checking package receipt...
Using packages DB: /cross/arm/sysroot/var/lib/tazpkg
Connecting to invisible-island.net (216.194.248.64:21)
ncurses-5.9.tar.gz 100% |*******************************| 2760k 0:00:00 ETA
Extracting: ncurses-5.9.tar.gz
Executing: compile_rules
CFLAGS : -march=armv6 -O2
Installing: ncursesw-extra
configure: loading site script /etc/slitaz/cook.site
checking for egrep... grep -E
Configuring NCURSES 5.9 ABI 5 (Sat Mar 1 04:24:22 UTC 2014)
checking build system type... i486-slitaz-linux-gnu
checking host system type... arm-slitaz-linux-gnueabi
checking target system type... arm-slitaz-linux-gnueabi
Configuring for linux-gnueabi
checking for prefix... /usr
checking for arm-slitaz-linux-gnueabi-gcc... arm-slitaz-linux-gnueabi-gcc
checking for C compiler default output... configure: error: C compiler cann
eate executables
Build dependencies to remove: 6
Removing: glibc-base/usr/bin/tazpkg: line 139: dirname: not found
/usr/bin/tazpkg: line 139: dirname: not found


    In the meantime, I've been trying to get native compilation to work. I got gcc to work with qemu-arm-static by side-stepping the issue and using tazpkg convert from Debian wheezy packages.

    https://github.com/pirandr/slitaz-arm/tree/master/wheezy-conversion

    Although it would need quite a bit more before I can start building things with it (and even more if we want to use cook to get tazpkg out of the things built this way).

    Posted 10 years ago #
14. 

    Trixar_za
    

    offline

    Key Master

    You know, this is one reason I want to make a Buildroot built flavour of SliTaz since cross-arch versions is just a rebuild away.

    Posted 10 years ago #
15. 

    pirandr
    

    offline

    Member

    Chrooted build environment

    For the moment, I've just commented out the call to remove_deps in cook, which probably doesn't make distributable packages but at least makes it much less annoying while I'm trying things.

    libxslt

    I've managed to cook libxslt, by accident. At first I was also getting the error message

    
/usr/lib/libxml2.so: could not read symbols: File in wrong format


    But then I moved /usr/lib/libxml2.so on the host (to something like /usr/lib/libxml2.so.old) and it cooked. Although there were some errors when it tried to download DTDs for xhtml, the package seems to have built.

    The packages built:

    https://github.com/pirandr/slitaz-arm/tree/master/cross-compiled

    The DTD errors:

    
Validating the HTML Web pages
I/O error : Attempt to load network entity http://www.w3.org/TR/xhtml1/DTD/xhtml
API.html:2: warning: failed to load external entity "http://www.w3.org/TR/xhtml1
1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"
^
API.html:3: validity error : Validation failed: no DTD found !
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type"
^
I/O error : Attempt to load network entity http://www.w3.org/TR/xhtml1/DTD/xhtml
bugs.html:2: warning: failed to load external entity "http://www.w3.org/TR/xhtml
1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"
^
bugs.html:3: validity error : Validation failed: no DTD found !


    I think the network just timed out. I was able to download those files later but the server took some time to respond.

    python

    It seems there are many superfluous dependencies for python. They are needed for for building certain modules but since python is sometimes a build dependency for other things that don't need those modules, might I suggest that python be split this into two separate packages: one minimal one called "python" without the deps and another called "python-full" (with the extra deps) or something like that?

    This is especially true now that C might not be needed while cross compiling for a host system some something like gdbm (which depends on gcc) is no longer needed as a dependency.

    I feel like the minimal version would have almost no dependencies.

    Here's an untested receipt. Its rather meant to describe how I cross-compiled python than a receipt proper (maybe someone more knowledgeable can make a real one). The problem is that the first part needs to be built on the host (since that binary will run to build the second part). Or maybe python itself can be a build dep but I don't know if the binary Parser/pgen (which is also needed to build python) is installed usually.

    https://github.com/pirandr/slitaz-arm/blob/master/cross-compiled/python-2.7.5-receipt

    I also managed to make a native build through qemu-arm-static without any trouble (no patches needed).

    The extra modules that would be missing are

    _sqlite3 _tkinter bsddb185
    gdbm sunaudiodev

    And now that I finished building it, I forgot what depends on it...

    Buildroot

    @Trixar_za: What is this sorcery? I'll have to try using buildroot later. At least if it can really combine the things it claims to be able to in menuconfig, I'm really impressed. For a distro-less build with rarely changing programs, this is perfect! (Rarely changing or all changes have to happen on a different machine anyway.)

    A Slitaz flavour would certainly be welcome.

    Posted 10 years ago #

RSS feed for this topic

Reply »

You must log in to post.