Re: [lfs-support] Architecture suggestion
On Sun, 15 Jul 2018 22:50:07 +0800
Xi Ruoyao wrote:
> On 2018-07-15 09:17 -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.
>
> 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.
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.wikipedia.org/wiki/Posting_style
Re: [lfs-support] Architecture suggestion
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-1-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 in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] Architecture suggestion
On 07/15/2018 08:17 AM, 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. 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-1-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? http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] Architecture suggestion
On 2018-07-15 09:17 -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.
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
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.wikipedia.org/wiki/Posting_style
Re: [lfs-support] Architecture suggestion
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. 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-1-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 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-- 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
Re: [lfs-support] Architecture suggestion
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 ? 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
[lfs-support] Architecture suggestion
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 in e-mail? http://en.wikipedia.org/wiki/Posting_style
