Re: [lfs-support] LFS 8.0 Chapter 5.10 GCC-6.3.0 - Pass 2

[Santi Moreno]

2017-03-23 2:56 GMT+01:00 Owen Cook :

>
>  ==
>
> Hi people, I can't compile with make in this pass, It return me this:
>
> ...
> i686-lfs-linux-gnu-g++ -c   -g -O2 -DIN_GCC -fno-exceptions -fno-rtti
> -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
> -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
> -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
> -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -I. -Ibuild -I../../gcc
> -I../../gcc/build -I../../gcc/../include  -I../../gcc/../libcpp/include  \
> -o build/genmddeps.o ../../gcc/genmddeps.c
> In file included from ../../gcc/genmddeps.c:19:0:
> ../../gcc/system.h:221:22: fatal error: algorithm: No such file or
> directory
>  # include 
>   ^
> compilation terminated.
> Makefile:2495: recipe for target 'build/genmddeps.o' failed
> make[2]: *** [build/genmddeps.o] Error 1
> make[2]: Leaving directory '/mnt/lfs/sources/gcc-6.3.0/build/gcc'
> Makefile:4146: recipe for target 'all-gcc' failed
> make[1]: *** [all-gcc] Error 2
> make[1]: Leaving directory '/mnt/lfs/sources/gcc-6.3.0/build'
> Makefile:886: recipe for target 'all' failed
> make: *** [all] Error 2
>
>
> Does anyone know where the error can come from?
> 
> IIRC
>
> The first pass uses gmp etc.
>
> You need to delete that first pass directory and build the second pass as
> per instructions.
>
>
Thanks for your reply. I have restarted the installation with more
attention and this error does not occur anymore.

Thanks.


>
>
>
> Owen
> --
> 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
>
-- 
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] Building LFS with an existing toolkit

[Michael Shell]

On Wed, 22 Mar 2017 17:26:38 +0100
Michele Bucca  wrote:

> Not all BIOSES support GPT. My old PC (2007) is still using a BIOS and does
> not support GPT I guess


AFAIK, it does not really matter if a BIOS recognizes a GPT - well,
unless you want to be able select a specific *partition* within the BIOS
boot options and AFAIK many/most BIOSes don't even support boot selection
for anything other than at the *drive* (MBR) level anyway.

The idea is that the boot loader, installed in the MBR at the start of
the boot disk (and even GPT disks still have an MBR where a boot loader
can be placed), is what actually selects which partition (or should I say
other sectors) to boot (load). So, as long as the boot loader can do
it's job, it really does not matter if the BIOS knows what the heck
a GPT is.

Furthermore, surprisingly enough, even the boot loader itself does not
have to understand GPT. For example, the venerable LILO boot loader can
work with with GPT disks because all it does is load in the requested
sector numbers for the second stage boot loader and then does the
same for the specific kernel image to load. As long as the BIOS can
retrieve the requested boot sectors from the bootloader by absolute
sector numbers alone, the boot system should work. 

And LILO et al. will "understand" what and where the partitions are as
long as the kernel does as in /dev/sXY when LILO et al. is run to
install the loader. i.e., GPT aware kernel = GPT compatible LILO,
at least when LILO is booted from an MBR (even the one within a
GPT disk).

Other than RAID setup problems, the main limitation with older boot
loaders such as LILO is that using 32bit sector numbers means that
it can only "reach" the first 2TB of drives using 512 bytes/sector.
That issue can be overcome, at least for Linux only systems, by
ensuring that /boot is a partition of it's own located within the
first 2TB. (Again, once we can get a kernel image into memory, we're
pretty much good to go as far as the boot process goes.)

Also, I don't know if LILO or the other older boot loaders can
handle modern 4096 byte / sector drives - and then there is the
512 byte/sector "emulation" angle on such modern drives.


Anyway, there seem to be only two potential problems with older BIOSes
with GPT disks, and they are both uncommon:

http://www.rodsbooks.com/gdisk/bios.html

One is that certain BIOSes want to see a bootable partition which won't
exist on standard GPT disks. This problem can be overcome simply by
setting the bootable flag on the protective MBR partition of the GPT
disk (via the experts' menu of gdisk).

Some uncommon older motherboards (e.g., Biostar PT880 Pro-A7, circa 2006)
require "believable" ancient C/H/S (cylinders, heads, sectors per track)
drive geometry info even though the system/drive is using the modern
sane LBA (sector number) addressing. Again, this can be overcome by
setting the protective MBR on a GPT disk to have the needed fake
(and meaningless anyway on drives made in the last 20-30 years) CHS
values (again via the experts' menu of gdisk).

In short, the uncommon BIOS problems with GPT can be overcome by
setting appropriate "lies" in the protective MBR using gdisk.


While on the subject, anyone else out there also think that UEFI is
overly complicated BS? - all they ever needed to do was extend the
old MBR system to overcome the partition number, sector addressing,
and first stage MBR boot loader size and number limitations:

http://yarchive.net/comp/linux/efi.html

  "From: Linus Torvalds
   EFI is this other Intel brain-damage (the first one being ACPI).
   It's totally different from a normal BIOS, and was brought on
   by ia64, which never had a BIOS, of course.

   Sadly, Apple bought into the whole "BIOS bad, EFI good" hype, so
   we now have x86 machines with EFI as the native boot protocol."


UEFI still does not overcome the need have to load any special drivers 
required to access add-on card boot devices (as if that were even
possible - we can't expect a system to be able to use hardware it
hasn't been taught to understand), and once a kernel can be loaded
into memory with all needed drivers, we're home free anyway.

Booting just boils down to just being able to select arbitrary blocks
of data (kernel images, each still only about 20MB of typical size
today) to load into memory and then execute.

Wouldn't have been better to have, say, a standard SDcard slot - a
"universal memory boot device (UMBD)" - on the motherboard which
can contain "files" of OS (kernel) images or boot loaders. The
images could be "addressed" by sector numbers alone, like memory
and not even need or use any specific filesystem. (IIRC, Grub
does something like this with its special EF02 "BIOS boot
partition".)

The BIOS could then select which SDcard image to load into memory
and execute it. One could also use one "OS image" for a more
sophisticated custom boot loader and then get any boot prompt,
custom logo, etc. from that