[lfs-support] Architecture suggestion

[Alan Corey]

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.

---
Sent from Alpine connected to Gmail on my 64-bit Raspberry Pi
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing

[Ken Moffat]

Post by Alan Corey
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 ?

And one expression :) RISC-V

ĸen
--
Keyboard not found, Press F1 to continue
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-

[Alan Corey]

Post by Ken Moffat

Post by Alan Corey
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.

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

Post by Ken Moffat
And one expression :) RISC-V
Äžen
--
Keyboard not found, Press F1 to continue
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Do not top post on this list.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
http://en.wikipedia.org/wiki/Posting_style

---
Sent from Alpine connected to Gmail on my 64-bit Raspberry Pi

[Xi Ruoyao]

Post by Alan Corey

Post by Ken Moffat

Post by Alan Corey
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.

I can tell, at least we have to modify gcc-pass1 and gcc-pass2 to make the
commands changing dynamic linker location working for other architectures.
Maybe:

sed 's@/lib[^/]*/ld[^:]*so@/tools&@g' -i `grep -lr ld.so gcc/config`

And the condition creating symlink /{tools,usr}/lib64 -> lib also need to
be modified for other architectures with multilib.

By the way, is CLFS dead now? I remeber CLFS supports many architectures.
--
Xi Ruoyao <***@stu.xidian.edu.cn>
School of Aerospace Science and Technology, Xidian University
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.w

[Alan Corey]

On Sun, 15 Jul 2018 22:50:07 +0800

Post by Xi Ruoyao

Post by Alan Corey

Post by Ken Moffat

Post by Alan Corey
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.

I can tell, at least we have to modify gcc-pass1 and gcc-pass2 to
make the commands changing dynamic linker location working for other
gcc/config`
And the condition creating symlink /{tools,usr}/lib64 -> lib also
need to be modified for other architectures with multilib.
By the way, is CLFS dead now? I remeber CLFS supports many
architectures.

No, as far as I know it's still around, I was just trying to cross over
early and build LFS on a Raspberry Pi because that's mostly what I've
been using for 6 months or so. My last dinosaur i386 machine died
sometime during the winter. My only x86_64 is a ratty old HP laptop I
bought on eBay for $1 to fix up for somebody, gave up on that so it
just logs temperature data.

I'm retired and just playing around really. And all this playing with
OSes is getting sidetracked from a couple programming projects I might
actually be able to wrap up in my lifetime. I like LFS for the sake of
being back to basics, not infested with zillions of little scripts
written by people assuming you were going to learn to do things their
way, ignoring underlying principles. And package systems, and
PAM/Selinux/Apparmor. More things build well under Linux than OpenBSD
or I'd still be using that. I'm convinced that politics are the
downfall of most distros.

So I'll try pilfs and try to cross from there since at least the build
system will be native to what I'm on.

Just seems like you could set up an abstraction layer that works a
little like Debian's /etc/alternatives or the roles that programs fit
into under Android. Abstract a program (or directory) to a role, and
what fits into that role depends on the situation. But maybe the
syntax is too different between them. If instead of /lib64 you used a
macro like $MYLIBDIR then that could point to /lib64
or /lib/arm-linux-gnueabihf. Define MYLIBDIR in the Bash profile in the
installation, it would only need to be set once. Not clfs exactly but
with switchable inputs as well as outputs. Huge amounts of time in
testing, unless you could automate parts. OpenBSD, NetBSD, even Linux
run on many platforms, but the low-level per-platform implementation is
a specialized thing. I'm in ARM mailing lists for Debian, OpenBSD,
NetBSD, not that I follow everything in much detail. Somewhere
there's a picture of rack-mounted build machines in Theo de Raadt's
basement, probably tended by a flock of grad students.

But back to work. I just want a generic unix machine that always
works. It's not my goal to spend a lot of time on the implementation,
that's getting sidetracked.
--
Sent from a Raspberry Pi with Claws mail.
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wik

[Bruce Dubbs]

Post by Alan Corey

Post by Ken Moffat

Post by Alan Corey
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.
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

That is not enough. When we make a release, we test every package in
both LFS an dBLFS. Right now that's done twice for System V and systemd.
It is very time consuming. We do not have the resources to do that
for additional architectures.

-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail

[Ken Moffat]

Post by Ken Moffat

Post by Alan Corey
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
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing