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, 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
[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
Re: [lfs-support] 5.7 glibc sanity check question
On 07/11/2018 12:59 PM, Bruce Dubbs wrote: On 07/11/2018 10:28 AM, Alan Corey wrote: OK, it fails. And when I do readelf -l a.out and look at the output manually the interpreter line is just [Requesting program interpreter: /lib/ld-linux-aarch64.so.1] No /tools in there. How does it get there? I configured glib with the little script #!/bin/bash ../configure --prefix=/tools --host=$LFS_TGT \ --build=$(../scripts/config.guess) --enable-kernel=3.2 \ --with-headers=/tools/include libc_cv_forced_unwind=yes \ libc_cv_c_cleanup=yes Built it all, it failed the sanity test and I was trying to figure out why. I thought --prefix only changed where something was installed, I didn't know it got embedded. Maybe this is like argv[0]. This is referencing ld-linux on the host, not the one in /tools. Are you building as user lfs? Is $LFS_TGT defined properly? -- Bruce Yes and yes. up64$ whoami lfs up64$ env LC_ALL=POSIX OLDPWD=/mnt/lfs/sources/glibc-2.27 LFS=/mnt/lfs NO_AT_BRIDGE=1 PWD=/mnt/lfs/sources/glibc-2.27/build HOME=/home/lfs LFS_TGT=aarch64-lfs-linux-gnu TERM=rxvt-unicode-256color SHLVL=1 PATH=/tools/bin:/bin:/usr/bin PS1=\h\$ _=/usr/bin/env up64$ readelf -l a.out | grep interpreter [Requesting program interpreter: /lib/ld-linux-aarch64.so.1] -- --- Sent from 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
[lfs-support] 5.7 glibc sanity check question
OK, it fails. And when I do readelf -l a.out and look at the output manually the interpreter line is just [Requesting program interpreter: /lib/ld-linux-aarch64.so.1] No /tools in there. How does it get there? I configured glib with the little script #!/bin/bash ../configure --prefix=/tools --host=$LFS_TGT \ --build=$(../scripts/config.guess) --enable-kernel=3.2 \ --with-headers=/tools/include libc_cv_forced_unwind=yes \ libc_cv_c_cleanup=yes Built it all, it failed the sanity test and I was trying to figure out why. I thought --prefix only changed where something was installed, I didn't know it got embedded. Maybe this is like argv[0]. This is referencing ld-linux on the host, not the one in /tools. And my /tools symlink is right, I think: up64$ ls -la / | grep tools lrwxrwxrwx 1 root root14 Jul 10 08:17 tools -> /mnt/lfs/tools I don't think this relects an error in this glibc, more like something before. But wait a minute, my cfg script may run with a different environment. Don't think so though. Tricks I've learned from a lot of unsuccessful builds in general: Put the configure stuff in a little script so you can edit and run again if needed. Redirect the output of configure or make into a file and probably do a tail -f on that to watch. I have the configure output. Running make over again. -- - No, I won't call it "climate change", do you have a "reality problem"? - AB1JX Impeach Impeach Impeach Impeach Impeach Impeach Impeach Impeach -- 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] Should the man page names have the triplet as a prefix?
On 07/10/2018 01:33 PM, Ken Moffat wrote:
On Tue, Jul 10, 2018 at 10:53:37AM -0400, Alan Corey wrote:
Like
aarch64-lfs-linux-gnu-as.1
or did I screw up again?
For (pseudo) cross-compiling (i.e. pass 1), that is ok.
In /mnt/lfs/tools/bin I have a set of executables with names like
aarch64-lfs-linux-gnu-as and in
/mnt/lfs/tools/aarch64-lfs-linux-gnu/bin there's another set with
normal names. Neither are symlinks to the other.
Use ls -i : they should be hardlinks to the same inode.
Yes, they are, I'm not used to seeing hard links
[...]
I just finished /lfs/chapter05/binutils-pass1.html I didn't try very
hard to figure out what
case $(uname -m) in
x86_64) mkdir -v /tools/lib && ln -sv lib /tools/lib64 ;;
esac
Is for because I'm not an x86_64 user. Should I have done something
similar for aarch64? It links something, that's all I know.
It all depends on the expected linker and library directories. For
x86_64 the initial expectation was multilib, so 64-bit libraries and
their linker are in {$PREFIX,}/lib64 - on LFS we do not support
multilib, everything can happily live in /lib with the symlink and
other step(s) shown for x86_64.
But my google-fu doesn't let me find out what the expected
directory/linker is (searching for linker got me to ld scripts and
information from gcc on the two -mabi variants for 32bit, 64bit,
searching for loader got me information on boot images).
So, I think it is VERY likely that you need the lib64 symlinks. But
if you get to glibc in chapter 6 I have no idea what the equivalent
of ld-linux should be.
Ah! Searching for aarch64 ld-linux got hits for
ld-linux-aarch64.so.1 so that is probably the correct name,
Confirmatory details at https://patchwork.openembedded.org/patch/80431/
On a page at linaro I found:
TRIPLET=arm-unknown-linux-gnueabi # or aarch64-unknown-linux-gnu
LINUX_ARCH=arm # use arm64 if building for an aarch64 target
I see both the arm64 and aarch64 in general. But the prefix seems to be used
mostly on the binutils stuff. On the host Pi I see:
lrwxrwxrwx 1 root root 5 Apr 4 06:16 aarch64-linux-gnu-cpp -> cpp-7
-rwxr-xr-x 1 root root 912128 Jun 15 08:29 aarch64-linux-gnu-cpp-6
-rwxr-xr-x 1 root root 981896 Jun 26 03:52 aarch64-linux-gnu-cpp-7
-rwxr-xr-x 1 root root1035192 Jun 26 04:45 aarch64-linux-gnu-cpp-8
-rwxr-xr-x 1 root root3384304 Jun 22 02:11 aarch64-linux-gnu-dwp
-rwxr-xr-x 1 root root 31424 Jun 22 02:11 aarch64-linux-gnu-elfedit
lrwxrwxrwx 1 root root 5 Apr 4 06:16 aarch64-linux-gnu-g++ -> g++-7
-rwxr-xr-x 1 root root 981896 Jun 26 03:52 aarch64-linux-gnu-g++-7
lrwxrwxrwx 1 root root 5 Apr 4 06:16 aarch64-linux-gnu-gcc -> gcc-7
-rwxr-xr-x 1 root root 912128 Jun 15 08:29 aarch64-linux-gnu-gcc-6
-rwxr-xr-x 1 root root 981896 Jun 26 03:52 aarch64-linux-gnu-gcc-7
-rwxr-xr-x 1 root root1035192 Jun 26 04:45 aarch64-linux-gnu-gcc-8
lrwxrwxrwx 1 root root 8 Apr 4 06:16 aarch64-linux-gnu-gcc-ar ->
gcc-ar-7
-rwxr-xr-x 1 root root 23072 Jun 15 08:29 aarch64-linux-gnu-gcc-ar-6
-rwxr-xr-x 1 root root 27104 Jun 26 03:52 aarch64-linux-gnu-gcc-ar-7
-rwxr-xr-x 1 root root 27104 Jun 26 04:45 aarch64-linux-gnu-gcc-ar-8
lrwxrwxrwx 1 root root 8 Apr 4 06:16 aarch64-linux-gnu-gcc-nm ->
gcc-nm-7
-rwxr-xr-x 1 root root 23072 Jun 15 08:29 aarch64-linux-gnu-gcc-nm-6
-rwxr-xr-x 1 root root 27104 Jun 26 03:52 aarch64-linux-gnu-gcc-nm-7
-rwxr-xr-x 1 root root 27104 Jun 26 04:45 aarch64-linux-gnu-gcc-nm-8
The aarch64-linux-gnu-gcc is a symlink pointing to aarch64-linux-gnu-gcc-7
right now.
Leaving the directory as-is for now and moving on
ĸen
--
---
Sent from 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
[lfs-support] Should the man page names have the triplet as a prefix?
Like aarch64-lfs-linux-gnu-as.1 or did I screw up again? In /mnt/lfs/tools/bin I have a set of executables with names like aarch64-lfs-linux-gnu-as and in /mnt/lfs/tools/aarch64-lfs-linux-gnu/bin there's another set with normal names. Neither are symlinks to the other. As the lfs user env says: LC_ALL=POSIX LFS=/mnt/lfs NO_AT_BRIDGE=1 PWD=/mnt/lfs/sources/binutils-2.30/build HOME=/home/lfs LFS_TGT=aarch64-lfs-linux-gnu TERM=rxvt-unicode-256color SHLVL=1 PATH=/tools/bin:/bin:/usr/bin PS1=\h\$ _=/usr/bin/env OLDPWD=/mnt/lfs/sources/binutils-2.30 I just finished /lfs/chapter05/binutils-pass1.html I didn't try very hard to figure out what case $(uname -m) in x86_64) mkdir -v /tools/lib && ln -sv lib /tools/lib64 ;; esac Is for because I'm not an x86_64 user. Should I have done something similar for aarch64? It links something, that's all I know. These are just temporary files but if there's a problem I should fix it before I go on. Binutils build went fine until I poked around in mc to see what had gotten created. - No, I won't call it "climate change", do you have a "reality problem"? - AB1JX Impeach Impeach Impeach Impeach Impeach Impeach Impeach Impeach -- 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] lfs-support Digest, Vol 969, Issue 1
On 07/09/2018 12:12 PM, Bruce Dubbs wrote: On 07/09/2018 10:14 AM, Alan Corey wrote: Please bear with me, I just turned off digest mode. I'll use filters and folders to deal with random traffic. I'm on Gmail, mostly use the web client. I'm still on half a dozen mailing lists but mostly I use forums these days. Trying to set up a real mail reader that does quoting properly. It probably won't be Thunderbird. I have years worth of mail in my Gmail account which with imap usually isn't a problem. Thunderbird is taking hours over this cell phone connection downloading something to catch up. My second choice would be Alpine. Anyway, trying to fudge some quoting here. Untar package cd package dir follow book, always remove the used dir after you have built it. Hmm, doesn't removing the directory cause "make uninstall" to not work? Guess I'll find out. We don't really address uninstall. That's really part of package management which we do not directly support. I suppose that's fine in my case, I tend to use software for a few years anyway. Did you also run the version check script chapter 2.2? Yes, looks fine. Whys is there no lost+found in /mnt/lfs? If you mounted your lfs partition on /mnt, it should be there. However the rest looks OK. The lost+found is in the partition outside the lfs dir. That's part of what I meant by it being confusing what you wanted. I initially created an /lfs mountpoint. This is /dev/sda2 mounted on /mnt and it has an lfs directory in it. That will not work. When you get to the point of rebooting into LFS, you need your build to be at the root of the file system. I suggest: umount /lfs mkdir -p /mnt/lfs mount /dev/sd?? /mnt/lfs As far as booting, with an ARM machine you can edit cmdline.txt which is a string that gets fed to the kernel and change root=/dev/mmcblk0p2 to something else. You also have to set the /etc/fstab but that's the one inside the image you're booting. The trick with one of these things is that the GPU boots first then that boots the CPU. There are open source ways to do that now, qemu I think mainly. But you also need an SD card driver. I changed it so /mnt/lfs is a mountpoint. Looks OK, except you did not mention the symbolic link: /tools -> /mnt/lfs/tools It's there as of yesterday. I'm trying to think of what the chroot is going to see, if I do a chroot /mnt/lfs it will see the tools dir as /tools so it works like the symink when I'm not chrooted. Got it. So your CPU is ARM, isn't it? I guess not many people on this list have experience with that architecture. This does not mean they can't help, but their support may be limited. Yes it is. The most significant differences I've found are the boot methods and the video coming from a GPU sharing board and memory with the CPU. And the default file system is an SD card. Other than that this $35 cigarette pack sized computer thinks it's a mainframe. I'm in the Debian, OpenBSD, NetBSD and FreeBSD ARM mailing lists BTW, 635 posts on https://www.raspberrypi.org/forums/. LFS is the new kid on my block. Does compiling a simple program work? Yes, I do it several times a week at least. I'd really rather be writing C than messing around with operating systems. But I sort of made a career of replacing operating systems, mostly Windows, retired now. together is easiest if you have a spare x86_64 partition where you I do, but not on this machine. Thinking ahead, I should be able to able to build images to work on several different types of architectures with this tools collection I'm setting up. One of those is x86_64, also a couple different arm64 ones That sounds good, but we suggest your first build be on x86_64 to minimize problems that may come up. Hmm, could I do it from OpenBSD? That's where the dead Linux partition is, I could only boot it into Linux from a livecd, or maybe something connected over USB. OpenBSD can read/write extfs2 but nothing later. It's a laptop, I can't just plug another drive into it. When it works right it triple boots OpenBSD, Linux or XP. Seems like it might work, if I could cross compile from OpenBSD to Linux. If that machine is some sort of Raspberry Pi, Yes, I have 5 of them now. This is running Debian: Linux version 4.16.0-2-arm64 (debian-ker...@lists.debian.org) (gcc version 7.3.0 (Debian 7.3.0-23)) #1 SMP Debian 4.16.16-2 (2018-06-22) The rest run Raspbian. I also have a Rock64 and a Pocket Beagle both with Debian. The ARMs outnumber the Intel and AMD about 3:1. Another thing that trips up new users is doing some things as root. I confess I've never administered a multi-user unix machine. I'm used to doing everything as root, it's hard to remember what works as non-root. But I'm trying to do as much of this as possible as the lfs user so lfs will own files and dirs. Doing everything as root is a recipe for problems. Eventually you will make a mistake yo
Re: [lfs-support] lfs-support Digest, Vol 969, Issue 1
Please bear with me, I just turned off digest mode. I'll use filters and folders to deal with random traffic. I'm on Gmail, mostly use the web client. I'm still on half a dozen mailing lists but mostly I use forums these days. Trying to set up a real mail reader that does quoting properly. It probably won't be Thunderbird. I have years worth of mail in my Gmail account which with imap usually isn't a problem. Thunderbird is taking hours over this cell phone connection downloading something to catch up. My second choice would be Alpine. Anyway, trying to fudge some quoting here. > Untar package cd package dir follow book, always remove the used dir > after you have built it. Hmm, doesn't removing the directory cause "make uninstall" to not work? Guess I'll find out. > Did you also run the version check script chapter 2.2? Yes, looks fine. > Whys is there no lost+found in /mnt/lfs? If you mounted your lfs > partition on /mnt, it should be there. However the rest looks OK. The lost+found is in the partition outside the lfs dir. That's part of what I meant by it being confusing what you wanted. I initially created an /lfs mountpoint. This is /dev/sda2 mounted on /mnt and it has an lfs directory in it. > Looks OK, except you did not mention the symbolic link: > /tools -> /mnt/lfs/tools It's there as of yesterday. I'm trying to think of what the chroot is going to see, if I do a chroot /mnt/lfs it will see the tools dir as /tools so it works like the symink when I'm not chrooted. Got it. > So your CPU is ARM, isn't it? I guess not many people on this list have > experience with that architecture. This does not mean they can't help, but > their support may be limited. Yes it is. The most significant differences I've found are the boot methods and the video coming from a GPU sharing board and memory with the CPU. And the default file system is an SD card. Other than that this $35 cigarette pack sized computer thinks it's a mainframe. I'm in the Debian, OpenBSD, NetBSD and FreeBSD ARM mailing lists BTW, 635 posts on https://www.raspberrypi.org/forums/. LFS is the new kid on my block. > Does compiling a simple program work? Yes, I do it several times a week at least. I'd really rather be writing C than messing around with operating systems. But I sort of made a career of replacing operating systems, mostly Windows, retired now. > together is easiest if you have a spare x86_64 partition where you I do, but not on this machine. Thinking ahead, I should be able to able to build images to work on several different types of architectures with this tools collection I'm setting up. One of those is x86_64, also a couple different arm64 ones. > If that machine is some sort of Raspberry Pi, Yes, I have 5 of them now. This is running Debian: Linux version 4.16.0-2-arm64 (debian-ker...@lists.debian.org) (gcc version 7.3.0 (Debian7.3.0-23)) #1 SMP Debian 4.16.16-2 (2018-06-22) The rest run Raspbian. I also have a Rock64 and a Pocket Beagle both with Debian. The ARMs outnumber the Intel and AMD about 3:1. > Another thing that trips up new users is doing some things as root. I confess I've never administered a multi-user unix machine. I'm used to doing everything as root, it's hard to remember what works as non-root. But I'm trying to do as much of this as possible as the lfs user so lfs will own files and dirs. I hope to build arm64 images to run on the Raspberry Pis and Rock64, and an x86_64 to replace a dead Debian partition on a laptop. Maybe I should do the x86_64 first since there aren't booting issues. I can burn it a CD/DVD and copy it to the laptop. On 7/8/18, lfs-support-requ...@lists.linuxfromscratch.org wrote: > Send lfs-support mailing list submissions to > lfs-support@lists.linuxfromscratch.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.linuxfromscratch.org/listinfo/lfs-support > or, via email, send a message with subject or body 'help' to > lfs-support-requ...@lists.linuxfromscratch.org > > You can reach the person managing the list at > lfs-support-ow...@lists.linuxfromscratch.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of lfs-support digest..." > > > Today's Topics: > >1. Re: Booting LFS with systemd (Michael Shell) >2. Building LFS under Debian (Alan Corey) >3. Re: Building LFS under Debian (spiky) >4. Re: Building LFS under Debian (spiky) >5. Re: Building LFS under Debian (Bruce Dubbs) > > > -- > > Message: 1 > Date: Sat, 7 Jul 2018 23:34:29 -0400 > From: Michael Shell > To: lfs-support@lists.linuxfromscratch.org > Subject: Re: [lfs-support] Booting LFS with systemd > Message-ID:
[lfs-support] Building LFS under Debian
LFS is a work of art, I can't believe it's been around 20 years and I'd never heard of it. 20 years ago I was downloading Slackware on floppies and lugging them home from college. The paths are sort of intricate to a newcomer though. There are the paths I see, the paths the chroot is going to see, then paths used as prefix and lib-path. At couple diagrams might help in the beginning. I'm still stuck on binutils, chapter 5, http://www.linuxfromscratch.org/lfs/view/stable/chapter05/binutils-pass1.html I started out making a mountpoint called /lfs to mount the partition I'm working in, then decided it was a bad idea. What I have looks like: /lost+found /media /mnt lfs sources binutils-2.30 build tools /opt /proc Filezilla has nice directory trees BTW if somebody wants to do screenshots for documenting. :) Anyway I'm not sure that's right. Does the page mean to make build inside of binutils or is it outside to be used again later? My $LFS is set to /mnt/lfs I made a little cfg script for consistency rather than doing it from memory, it's mostly copied from the web page: #!/bin/sh ../configure --prefix=/tools\ --with-sysroot=$LFS\ --with-lib-path=/tools/lib \ --target=$LFS_TGT \ --disable-nls \ --disable-werror configure echos it back as ../configure --prefix=/tools --with-sysroot=/mnt/lfs --with-lib-path=/tools/lib --target=aarch64-lfs-linux-gnu --disable-nls --disable-werror in the config.log. OK, I'll attach the log. What worries me is the gcc: error trying to exec 'as': execvp: Too many levels of symbolic links In the conftest. Debian has this kludgy alternatives system where gcc is /usr/bin/gcc but that's lrwxrwxrwx 1 root root 5 Apr 4 06:16 gcc -> gcc-7 and that's lrwxrwxrwx 1 root root 23 Jun 26 03:52 gcc-7 -> aarch64-linux-gnu-gcc-7 And aarch64-linux-gnu-gcc-7 is the real name of gcc 7 maybe that's just part of conftest but configure dies with an error and no makefile. as is: as -> aarch64-linux-gnu-as in /usr/bin These kludgy scripts, and PAM/Selinux/Apparmor are what I'm hoping to get away from with linuxfromscratch. Yes, I usually have a few gcc and as and g++ versions around but it seems like there should be a better way. Alan -- - No, I won't call it "climate change", do you have a "reality problem"? - AB1JX Impeach Impeach Impeach Impeach Impeach Impeach Impeach Impeach This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by configure, which was generated by GNU Autoconf 2.64. Invocation command line was $ ../configure --prefix=/tools --with-sysroot=/mnt/lfs --with-lib-path=/tools/lib --target=aarch64-lfs-linux-gnu --disable-nls --disable-werror ## - ## ## Platform. ## ## - ## hostname = up64 uname -m = aarch64 uname -r = 4.16.0-2-arm64 uname -s = Linux uname -v = #1 SMP Debian 4.16.16-2 (2018-06-22) /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = unknown /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown /usr/bin/hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /tools/bin PATH: /bin PATH: /usr/bin ## --- ## ## Core tests. ## ## --- ## configure:2304: checking build system type configure:2318: result: aarch64-unknown-linux-gnu configure:2365: checking host system type configure:2378: result: aarch64-unknown-linux-gnu configure:2398: checking target system type configure:2411: result: aarch64-lfs-linux-gnu configure:2465: checking for a BSD-compatible install configure:2533: result: /usr/bin/install -c configure:2544: checking whether ln works configure:2566: result: yes configure:2570: checking whether ln -s works configure:2574: result: yes configure:2581: checking for a sed that does not truncate output configure:2645: result: /bin/sed configure:2654: checking for gawk configure:2670: found /usr/bin/gawk configure:2681: result: gawk configure:4005: checking for gcc configure:4021: found /usr/bin/gcc configure:4032: result: gcc configure:4261: checking for C compiler version configure:4270: gcc --version >&5 gcc (Debian 7.3.0-24) 7.3.0 Copyright (C) 2017 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:4281: $? = 0 configure:4270: gcc -v >&5 Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/7/lto-wrapper Target: aarch64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 7.3.0-24' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=aarch64-linux-gnu- --enable-shared
