On Wed, 2021-03-24 at 12:55 +0100, Patrick Frisch wrote:
> Hi there,
> I'm a big fan of the LFS project and build a system from time to time. My
> last build was a bit outdated so I decided to begin from scratch. I realized,
> that there are major changes in the build procedure for the toolchain lately.
> The last time I did it, the toolchain was build completely in chapter 5 :-),
> so maybe I missed some very clever improvements.
> However, I'm stuck in a very early stage, the linux api headers, where the
> last install command is
>
> cp -rv usr/include $LFS/usr
>
>
>
> This command copies all the subfolders of usr/include directly to $LFS/usr on
> my host system (arch linux). So later on (glibc build) these are expected in
> $LFS/usr/include (where they should be).
The `cp' command copies "include" and all its subdirs to $LFS/usr. So they land
where they are expected to land.
> As I said, the concept to use directories outside of $LFS/tools in this early
> stage is new to me and I have my issues with that. Glibc fails to build
> because of two reasons, on is that it doesn't find the api headers, the other
> reason is the very first command
> case $(uname -m) in
> i?86) ln -sfv ld-linux.so.2 $LFS/lib/ld-lsb.so.3
> ;;
> x86_64) ln -sfv ../lib/ld-linux-x86-64.so.2 $LFS/lib64
> ln -sfv ../lib/ld-linux-x86-64.so.2 $LFS/lib64/ld-lsb-x86-64.so.3
> ;;
> esac
> I don't understand this completely. Here you assume the build process to be in
> a specific directory. In my case (x86_64) where is '..' and there is no
> $LFS/lib64 od $LFS/lib at this stage.Normally here I am in the freshly
> unpacked glibc tarball, so .. is my src-directory (happens to be $LFS/src) but
> I will not find the libraries there.
> If I'm completely wrong with my question here, I apologize in advance and you
> may kindly advise me to the documentation I may have missed.
>
Well, maybe review the man page for ln (the -s option): what you create is a
symlink, a small file just pointing to a file, whose path is relative to the
symlink _itself_.
There should be $LFS/lib64 and $LFS/lib at this stage (they were created in
chapter 4).
So, for example:
ln -sfv ../lib/ld-linux-x86-64.so.2 $LFS/lib64
will create a file named ld-linux-x86-64.so.2 in $LFS/lib64, and that file just
points to ../lib/ld-linux-x86-64.so.2 respective to itself, that is $LFS/lib/ld-
linux-x86-64.so.2.
We have tried to explain the new build at the beginning of chapter 5. The
rationale for the new build is that maintaining a {$LFS,}/tools directory
isolated from the host during chapter 5, and then preventing the packages in
chapter 6 from using libraries in /tools was becoming more and more complex.
It is much easier to use the standard tools of cross compilation (where
isolation is built in), now that almost all packages behave correctly when cross
compiling. Of course, that creates other problems, especially for package
management, because packages in chapter 8 overwrite those built in the preceding
chapters. But it has been thought that the maintainability is easier in that
case.
Pierre
--
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
