gnu-linux-libre
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNU-linux-libre] ppc64el support in endorsed distros


From: Andreas Grapentin
Subject: Re: [GNU-linux-libre] ppc64el support in endorsed distros
Date: Thu, 31 May 2018 21:44:07 +0200
User-agent: Mutt/1.10.0 (2018-05-17)

Ha, this is so interesting. I have done almost the same thing for the
parabola riscv64 port:

https://git.parabola.nu/~oaken-source/parabola-riscv64-bootstrap.git/

However, the powerpc64le port process currently segfaults in glibc -
I'll check out what you're doing differently, maybe that gets us
forward.

Thanks for the pointers!

-Andreas


On Thu, May 31, 2018 at 03:34:01PM -0300, Matias Fonzo wrote:
> 
> Hello Denis,
> 
> The maintainer of Dragora GNU/Linux-Libre here.
> 
> Since 2012 I have started to re-do the distribution from scratch, the
> method that I propose is that the distribution can be built from
> scratch.  The method consists in simple shell scripts but well-organized
> in stages.  For example, the stage 0 build a cross-compiler, the other
> current stages are designed as a previous steps to get the final
> system.  Something like LFS and CLFS does, but I consider the method is
> a bit beyond of those (because I understand how LFS/CLFS works).
> Unlike LFS/CLFS, there two important aspects, 1) all the components are
> 100% free software. 2) the method is agnostic, you can modify, create or
> add the steps that you want to achieve for a stage (for example, to
> create other gnu/linux distributions).  When I said that the method is
> agnostic, this is especially for the stage 0, the cross-compiler.  This
> does not contain hard coded paths.
> 
> The independence of the cross compiler is such that I have managed to
> produce several cross compilers that use a non-convenient form.  The
> first phase, where a cross-compiler for the native architecture is
> created; and the second phase, where the produced cross-compiler is
> used to create other compilers for the different supported
> architectures.  The only cons maybe for you or other people, is that
> the set is based on the musl C library.
> 
> I've published a recent version, which contains support for the
> ppc64le, if you want to give a try:
> 
> http://lists.nongnu.org/archive/html/dragora-users/2018-05/msg00000.html
> 
> I can provide more information about the bootstrap method, etc. Let me
> know!
> 
> On Thu, 31 May 2018 12:46:32 +0200
> Denis 'GNUtoo' Carikli <address@hidden> wrote:
> 
> > On Fri, 18 May 2018 10:41:41 +0200
> > Andreas Grapentin <address@hidden> wrote:
> > 
> > Hi,
> >  
> > > I have been involved in that a bit, and I think the current problem
> > > is creating a suitable cross toolchain to start the port in
> > > earnest. If we had people with experience and ideas in that regard,
> > > that might me very helpful.  
> > I'm very interested in being able to create arbitrary toolchains from
> > an FSDG distribution, as I need it to be able to compile older
> > (ARM) kernels, compile lm32 code for some AMD processor (SMU) present
> > in AMD CPUs, etc.
> > 
> > == Cross toolchains ==
> > In Parabola we have crosstool-ng but I didn't spend enough time
> > on it to successfully create a toolchain.
> > > $ pacman -sS crosstool
> > > pcr/crosstool-ng 1.23.0-1.parabola1
> > >     Versatile (cross-)toolchain generator, with Linux-libre kernel
> > > support pcr/crosstool-ng-git 1.22.0.r21.g2d3c70d-1.parabola2
> > >     Versatile cross-toolchain generator, with Linux-libre kernel
> > > support  
> > 
> > Another approach would be to add support for that architecture in Guix
> > and build the toolchain through that.
> > 
> > I remember seeing compatibility the results of test in tables with
> > the combination of different versions of glibc, gcc, and binutils for
> > each architecture. Typcally, with x86, combining most of the
> > glibc, gcc, and binutils versions will work, whereas you might hit
> > problematic bugs when you do that for other less-scrutinized
> > architectures.
> > 
> > In any case, building a toolchain is not enough, you also need it to
> > work enough to bootstrap enough userspace to be able to boot (and
> > then be able to build packages and the toolchain on the booted
> > system).
> > 
> > == Using another distro ==
> > Another approach would be to use any GNU/Linux distribution (which is
> > not necessarily FSDG compliant) that supports ppc64 little-endian, run
> > it in qemu, and with it bootstrap a Parabola for ppc64 little-endian.
> > 
> > In one hand this may seem ethically acceptable[1]:
> > > But there is one special case where using some nonfree software, and
> > > even urging others to use it, can be a positive thing. That's when
> > > the use of the nonfree software aims directly at putting an end to
> > > the use of that very same nonfree software.  
> > 
> > But if you see it with another point of view it might be problematic
> > as it would be preferable not have to run non-FSDG distributions to
> > port FSDG distributions to other architectures in general. And porting
> > Parabola to ppc64 little-endian will not enable to avoid running
> > non-FSDG distributions when porting to a different architecture.
> > 
> > It would also be nice to be able to create arbitrary toolchains with
> > FSDG compliant software.
> > 
> > References:
> > -----------
> > [1]https://www.gnu.org/philosophy/is-ever-good-use-nonfree-program.html
> > 
> > Denis.
> 

-- 

------------------------------------------------------------------------------
my GPG Public Key:                 https://files.grapentin.org/.gpg/public.key
------------------------------------------------------------------------------

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]