[lfs-support] Architecture suggestion

Ken Moffat zarniwhoop at ntlworld.com
Sun Jul 15 11:27:58 PDT 2018


On Sun, Jul 15, 2018 at 09:17:26AM -0400, Alan Corey wrote:
> On Sun, 15 Jul 2018, Ken Moffat wrote:
> 
> > On Sat, Jul 14, 2018 at 08:49:19PM -0400, Alan Corey wrote:
> > > Would it be correct to replace x86_64 in your documentation bash scripts
> > > with `uname -m`?  Because of course everybody knows ARM is the way of the
> > > future.  :)
> > > 
> > > But seriously, I'm not always sure what to relace.  Or maybe you could put
> > > them all on one page?  It wouldn't detract from the flow of the main page
> > > much that way.
> > > 
> > 
> > You think we know the details for architectures we don't use ?
> > 
> 
> Oh, that seems simple enough, you put the ones you know on a web page and at
> the bottom appears a dedicated email address people can send them to. You'd
> probably get a few bogus ones, but look through them once a week or so and
> update the page.
> 

No, pointless work.  The *whole* project (LFS and BLFS) doesn't have
the people / time available, our current concern is with BLFS (see
the BLFS lists, do not discuss it on this list).

And also inadequate (more comments below) -

> pi2 (raspbian)
> Linux pi2 4.14.34-v7+ #1110 SMP Mon Apr 16 15:18:51 BST 2018 armv7l GNU/Linux
> 
> zero
> Linux zero 4.14.50+ #1122 Tue Jun 19 12:21:21 BST 2018 armv6l GNU/Linux
> 
> rock64
> Linux rock64 4.4.126-rockchip-ayufan-239 #1 SMP Sun May 27 18:38:24 UTC 2018 aarch64 GNU/Linux
> 
> up64 (Debian)
> Linux up64 4.16.0-2-arm64 #1 SMP Debian 4.16.16-2 (2018-06-22) aarch64 GNU/Linux
> 
> Motorola Android phone
> Linux localhost 3.10.49-g824dd55-00001-g217f0f1 #1 SMP PREEMPT Sat Feb 7 11:53:4
> 4 CST 2015 armv7l GNU/Linux
> 
> hp
> Linux hp 3.16.0-4-amd64 #1 SMP Debian 3.16.43-2 (2017-04-30) x86_64 GNU/Linux
> 

1. For the last item, it is standard x86_64, adding details of
individual manufacturers / model families provides nothing of use in
x86.

2. The other items each have exactly one piece of useful information
(armv7l, armv6l, aarch64) which is the output from 'uname -m'.

3. You will also need to know:

· the loader

· the name/version of libc

· the target triplet for gcc

You can find all of these in two steps:

(i) run ldd on a minimal program (e.g. /bin/true or something you
compiled yourself).  On LFS x86_64 that shows the vdso (part of the
kernel) and

 libc.so.6 (in /lib on lfs) - so that is the name/version of libc

 /lib64/ld-linux-x86_64.so - this is the loader, and it also tells
  you that /lib64 is the expected directory, which is why LFS does
  the modification on x86_64.

In older versions of LFS x86_64 we hacked things around to just
use /lib, at the cost of not being able to run "standard" binaries
(we mostly don't care about binaries, but some people do).  On other
host distros, particularly for embedded architectures, they might
have done that.  So for 64-bit CPUs it is still best to look at the
files for gcc (what we do in gcc pass 2) to confirm the library
directory - for real fun, consider building on mips which has 3
library-directory versions (see clfs).

(ii) look in /usr/lib*/gcc/ - the directory here is the target
triplet (or, the directories are the target triplets if multilib).

But not everything uses glibc, on some of those machines, using
musl might make more sense (I think the clfs-embedded book covered
musl on some form of arm CPU) - the details of above items _might_
be different.


But that will not tell anybody about the necessary differences.  I
pointed you to pilfs (for pi) in my reply to your initial posting
and from a quick look there were various essential changes, as
expected (my only non x86 experience was years ago on ppc and that
showed that too had different essential packages).

I would have pointed you to clfs in my first reply, but I could not
find any recent commits there.  For the architectures it covers it is
a good source of details about the differences [ clfs.org - look at
the "Read the Cross Linux From Scratch Book Online" in the TOC at the
right of the page ].

Building on different hardware can be fun (for normal tech values of
'fun') but if the exercise is to be useful it should then be
documented online where people can find it.  That is way outside the
scope of LFS.

ĸen
-- 
              Keyboard not found, Press F1 to continue


More information about the lfs-support mailing list