[lfs-support] Architecture suggestion

Alan Corey alan01346 at gmail.com
Sun Jul 15 17:02:01 PDT 2018


On Sun, 15 Jul 2018 22:50:07 +0800
Xi Ruoyao <ryxi at stu.xidian.edu.cn> 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.


More information about the lfs-support mailing list