Re: Any arch support

[ Thread Index | Date Index | More lists.tuxfamily.org/slitaz Archives ]


I still don't like the idea of multiarch just cause its going to be not easy to make my slitaz-tank isos anymore. So i will not be able support other anyways since slitaz-tank was meant for x86 only so we only have to have 1 type of arch. Its why i used slitaz in first place. It was simple. With multiarch it can't be done so simply. I know this cause i did try looking at making a source dvd like slitaz-tank on archlinux back in 2010.

So arm and x86_64 will have not support in my slitaz-tank. X86_64 can be done by simply making a linux-pae since that will allow up to 64gb of ram installed of 4gb. Thats the main reason to move to x86_64 anyways and no computer being sold today has 64gb or more in them by default.

I just thought you should know slitaz-tank will just have to be a subproject and nothing offical cause of no multiarch support.

On Mon, May 14, 2012 at 7:52 PM, Christophe Lincoln <pankso@xxxxxxxxxx> wrote:

Hi,

First, we have now 2 cross environment up and running on Tank with
both toolchain build and rebuildable with the new 'cross' tool. The ARM
port is now quiet well tested by me and x86_64 is getting better day
after day. But we still in a testing stage, path may changes, cross
will be improved and fixed, so no stress about packages but we must
think about it.

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

In all case we have to change tazpkg/spk to install the correct
packages for the given arch. To know on witch platform SliTaz is
running I have introduced SLITAZ_ARCH in /etc/slitaz/slitaz.conf, the
package manager must used it.

"Actually, the whole multi arch system is complicated, non-kiss and
looks awful."

Usual complain without any patch attached :-/ This is how I worked thes
last weeks and how I work to have multiarch chroot and cookers:

One chroot by arch --> dont mess-up files, safer
/home/slitaz/VERSION/ARCH/chroot with the usual tree. I have adapted
tazdev for multiarch (use last on from repo), to create an ARM chroot
and chroot:

# tazdev gen-chroot --arch=arm
# tazdev -c --arch=arm

Then clone cookutils repo and install-cross from inside or outside the
chroot, but use last cross. Edit config or at least check variables,
when ready with cross and it cross.conf file installed you can compile
the all toolchain at once (take more than an hour on tank):

# cross compile

Cross will compile a toolchain targeting the ARM paltform, these tools
will never run on ARM but on the build machine to produce code for
the target arch. It's why I dont use --build= in cross, so it build
binaries optimised for the build host (ie: i686 for tank). After hours
and hours of testing I came the the conclusion that use a single script
like cook is much more easier than make cross-arch-* packages, at least
for now since cross-compiling is NOT simple by itself.

For more info please read 'cross' documentation in cookutils source or:
http://hg.slitaz.org/cookutils/raw-file/tip/doc/cross.txt

I think it would be nice to use --with-sysroot= for cross-tools, ther
is an option in 'cross' but more work and testing is needed.

If you have code providing an other WORKING solution, please share. If
you have patches for cross, please sent them or add them in a patch
directory in cookutils.

> will have do like subfolders like any and then $ARCH folder. The idea
> is to use softlinks from any folder and put then in $ARCH. So
> packages folder will be more like this:
> packages/$ARCH
> packages/any

Yes this look nice but I think we can do without any symlink. We need
the package manager use any/packages.list for all arch then use
SLITAZ_ARCH to set: packages/$ARCH

> This way we don't need a cookutils-2.0.tazpkg and
> cookutils-2.0-arm.tazpkg since cookutils should work just fine as one
> package on both systems. This will also be helpful for perl, python,
> and docs packages.
>
> This is cause a idea for now. We will have to see if it can be done
> without breaking everything.

Nice idea! Why not implement that in spk/tazpkg yourself ?

> PS We need to add a way to rebuild packages database without wok. I
> have this in my-cookutils. This is just to make it simple to make
> package database.

Ok, can you add an updated patch in cookutils/patch so I can test it
with the current cook, I'm not agains changes in cook but want to
review any patch and get them in one by one. This because cook is up
for one year now without critical bugs and it just work.

- Christophe

--
SliTaz GNU/Linux Mailing list - http://www.slitaz.org/




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/