On Thu, Jan 21, 2021 at 01:21:15PM +0100, Pol Vangheluwe wrote:
> (first some context, my question follows at the end of this mail)
> A few weeks ago, there was a (animated) discussion on one of the mailing
> lists (don’t remember exactly which one)) about howto transfer LFS from one
> machine to another and the use of a package manager.
> This threead was not only interesting from a technical viewpoint, but also to
> learn about human behaviour on the Internet.
>
> Anyway, this made me wonder if it would be possible to copy LFS-8.1, built on
> an iMac G3, to a PowerMac-G3-Server.
> Although both machines are based on the G3 PowerPC, they are quite different.
> - the CPU is not exactly the same. The PowerMac has revision : 2.2 (pvr 0008
> 0202), while the iMac has revision : 2.2 (pvr 0008 0202)
I think you've quoted the same data twice ? When I had a ppc G3
linux laptop I think that the CPU was described as '750' and that
was one of the last of the G3s. But that was a very long time ago
so I don't think I can help re CPU differences, although both will
be incredibly slow by modern standards.
The current (5.10.9) kernel docs are in rst format in the kernel's
Documentation/powerpc directory. I'm not sure what kernel you are
running, and the docs used to be in different formats, but I can see
from cpu_families.rst that there were variants of the 750 (755,
750CX, 750CL, 750FX). I don't recall if the CPU variant got
specified in the kernel config when I was building on ppc32, but
looking at cpu_features.rst suggests this gets setup automatically
in early boot so that one kernel can cover several variations of the
hardware.
Therefore, for getting a working kernel config I think that you
really need to look at the help for all of the mac options, and
remove what is not present and add what is present but not enabled.
For the gmp problem, see below.
> - but most of all, the surrounding chipset is different. The
> PowerMac-G3-Server uses mainly third party chips, while the iMac uses Apple
> chips:
>
> pol@PowerMac-G3:~$ lspci
> 9f08:00:00.0 Host bridge: Motorola MPC106 [Grackle] (rev 40)
> 9f08:00:0d.0 PCI bridge: Digital Equipment Corporation DECchip 21154 (rev 02)
> 9f08:00:10.0 VGA compatible controller: Advanced Micro Devices, Inc.
> [AMD/ATI] Rage 128 GL PCI
> 9f08:01:00.0 FireWire (IEEE 1394): Texas Instruments PCILynx/PCILynx2 IEEE
> 1394 Link Layer Controller (rev 02)
> 9f08:01:01.0 IDE interface: Silicon Image, Inc. PCI0646 (rev 07)
> 9f08:01:04.0 SCSI storage controller: Adaptec AHA-2940U2/U2W (rev 01)
> 9f08:01:05.0 Unassigned class [ff00]: Apple Inc. Paddington Mac I/O
> 9f08:01:06.0 USB controller: OPTi Inc. 82C861 OHCI USB Host (rev 10)
>
> pol@iMac-G3:~$ lspci
> 0000:10:0b.0 Host bridge: Apple Inc. UniNorth PCI
> 0000:10:17.0 Unassigned class [ff00]: Apple Inc. KeyLargo Mac I/O (rev 02)
> 0000:10:18.0 USB controller: Apple Inc. KeyLargo USB
> 0000:10:19.0 USB controller: Apple Inc. KeyLargo USB
> 0001:20:0b.0 Host bridge: Apple Inc. UniNorth Internal PCI
> 0001:20:0e.0 FireWire (IEEE 1394): Apple Inc. UniNorth FireWire (rev 01)
> 0001:20:0f.0 Ethernet controller: Apple Inc. UniNorth GMAC (Sun GEM) (rev 01)
> 9f08:00:0b.0 Host bridge: Apple Inc. UniNorth AGP
> 9f08:00:10.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Rage
> 128 VR AGP
>
> I started by making a backup of the LFS-partition on the iMac, transferred it
> to the PowerMac and untarred it.
> I could chroot in the LFS image on the Powermac to adapt the fstab table.
> I updated the yaboot configuration, adding LFS, next to the host system
> (Ubuntu-16.4.7-LTS).
> I realised that the /home folder on the donor machine was on a separate
> partition (but not on the recipient machine), so I had to transfer this
> partition as well.
An alternative for kernel configuration would be to use lspci and
lsmod in ubuntu to see what is present, and to use that as the
starting point - build-in devices which are present and in use,
leave the rest as modules.
> I booted into LFS and got the (meanwhile well-known) message
>
> Kernel panic – not syncing : VFS : Unable to mount root fs on unknown - block
> (0,0)
>
> This means mostly that a driver is missing, needed to access the boot device.
> More specifically, a driver that is not needed on the iMac with its Apple
> chipset.
> I recompiled several times the kernel, adding (non-Apple) SCSI drivers (and
> not as a module!).
> Finally, it looked like adding the “Future Domain 16xx SCSI/AHA-2920A
> support” was a hit. The boot process continues, but gets an exception a bit
> further and falls in the monitor.
> At this point, I got stuck. I tried several other kernel configuration
> options, even tried booting with INITRAMFS, but never came beyond the kernel
> exception trap.
>
> Then I thought that rebuilding GMP might help. The CPUs are not 100%
> identical, so GMP was probably optimised for the iMac-G3, but not for the
> PowerMac-G3.
> However I got this configuration error:
>
> checking C++ compiler g++ -m32 -O2 -pedantic -mcpu=750... no, std iostream
> checking C++ compiler g++ -g -O2... no, std iostream
> configure: error: C++ compiler not available, see config.log for details
>
> and in config.log:
>
> /* This test rejects OSF 5.1 Compaq C++ in its default pre-standard iostream
> mode, since that mode puts cout in the global namespace, not "std". */
> void someoutput (void) { std::cout << 123; }
>
> int main (void) { return 0; }
> configure:10650: result: no, std iostream
> configure:10521: checking C++ compiler g++ -g -O2
> Test compile:
> configure:10535: g++ -g -O2 conftest.cc >&5
> configure:10538: $? = 0
> configure:10542: ./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest
> configure:10545: $? = 0
> Test compile: namespace
> configure:10575: g++ -g -O2 conftest.cc >&5
> configure:10578: $? = 0
> configure:10582: ./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest
> configure:10585: $? = 0
> Test compile: std iostream
> configure:10621: g++ -g -O2 conftest.cc >&5
> In file included from /usr/include/c++/7.3.0/ext/string_conversions.h:41:0,
> from /usr/include/c++/7.3.0/bits/basic_string.h:6349,
> from /usr/include/c++/7.3.0/string:52,
> from /usr/include/c++/7.3.0/bits/locale_classes.h:40,
> from /usr/include/c++/7.3.0/bits/ios_base.h:41,
> from /usr/include/c++/7.3.0/ios:42,
> from /usr/include/c++/7.3.0/ostream:38,
> from /usr/include/c++/7.3.0/iostream:39,
> from conftest.cc:3:
> /usr/include/c++/7.3.0/cstdlib:75:15: fatal error: stdlib.h: No such file or
> directory
> #include_next <stdlib.h>
> ^~~~~~~~~~
> compilation terminated.
> configure:10624: $? = 1
> failed program was:
> /* This test rejects g++ 2.7.2 which doesn't have <iostream>, only a
> pre-standard iostream.h. */
> #include <iostream>
>
> /* This test rejects OSF 5.1 Compaq C++ in its default pre-standard iostream
> mode, since that mode puts cout in the global namespace, not "std". */
> void someoutput (void) { std::cout << 123; }
>
> int main (void) { return 0; }
> configure:10650: result: no, std iostream
> configure:10666: error: C++ compiler not available, see config.log for details
>
> while stdlin.h seems to exist (on both machines):
>
> root [ /sources/gmp-6.1.2 ]# locate stdlib.h
> /home/pol/freetype-2.8/include/freetype/config/ftstdlib.h
> /sources/blfs/cpio-2.12/gnu/stdlib.h
> /sources/linux-4.15.7/arch/powerpc/boot/stdlib.h
> /usr/include/bash/include/ansi_stdlib.h
> /usr/include/bits/stdlib.h
> /usr/include/c++/7.3.0/stdlib.h
> /usr/include/c++/7.3.0/tr1/stdlib.h
> /usr/include/freetype2/freetype/config/ftstdlib.h
> /usr/include/stdlib.h
> /usr/share/doc/python-3.6.2/html/tutorial/stdlib.html
> /usr/share/doc/python-3.6.4/html/tutorial/stdlib.html
>
> I went back to the iMac, tried rebuilding GMP there, and got exactly the same
> configuration error.
> Now my question: why can’t I recompile GMP-6.1.2? I did it successfully back
> in 2018, when I built LFS-8.1.
>
> pvg
>
I can recall a few problems in the less-distant past where there
were problems with include_next in C++. I'm sure there have been
more recent reports. The first relevant item found by duckduckgo
was apparently from about 3 years ago,
https://blfs-dev.linuxfromscratch.narkive.com/so2k0krL/math-h-no-such-file-or-directory-from-gcc
and there Pierre suggested that some headers might have been
'include-fixed' when they should not have been.
At that time he suggested running
/usr/libexec/gcc/x86_64-pc-linux-gnu/7.3.0/install-tools/mkheaders
Obviously your version and triplet will differ, and it's possible
that LFS had not moved to using /usr/libexec when LFS-8.1 was
created (I think we used to try to force /usr/lib).
Before replying, I tried google and found what I was thinking of:
https://www.mail-archive.com/blfs-support@lists.linuxfromscratch.org/msg07176.html
and from that thread I remembered why it was in my "I'm sure I've
been bitten by this" thoughts (turns out it bit me in early December
when I was trying jhalfs for building blfs) - in BLFS's setup for
Xorg we now warn that messing about with the profile is only for
people who don't build Xorg in /usr. The problem, as Chris Gorman
found, was that C_INCLUDE_PATH and CPLUS_INCLUDE_PATH were now
putting /usr/include at the start of the search path and that is
catastrophic.
So, if you have /usr/include at the beginning of those INCLUDE_PATHs
change them to omit /usr/include.
BUT: these stdlib problems are only for C++ code, the kernel uses C.
ĸen
--
The right of the people to keep and arm Bears, shall not be infringed.
--
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
