Re: Moving to Grub2?
> Hello, > > I started working on bringing in compatible boot loaders for use with > x86_64 (and, possibly, PowerPC). The idea at first was just to move all > bootloaders down to chapter 8 and list which ones are compatible for > which arch/setup. > > I have started on that route already, see here: > > http://www.linuxfromscratch.org/~jhuntwork/lfs-trunk/ > > But as I'm working on this, I figured I'd pop in to grub2 headquarters > and see what the status is. I know that historically, this community > hasn't really been too fond of grub2 because of all the perceived > attention spent on bells and whistles. > > Still, the idea of one bootloader that works for nearly all hardware > (their site says: It is working on PC, OpenFirmware-based PowerPC > machines (PowerMac and Pegasos) and EFI-based PC (IntelMac)), it's just > too attractive to ignore completely. > > The latest version is 1.96, released in February of this year. Has > anyone tested this yet? > I did some work on the PowerPC GRUB2 implementation some time ago and have not looked at it in a while. I took some pictures of an OpenSolaris/Solaris Nevada situation on PowerPC back then and still have them around : http://www.blastwave.org/dclarke/grub2/03_Jul_2007/grub2_000.jpg http://www.blastwave.org/dclarke/grub2/03_Jul_2007/grub2_001.jpg http://www.blastwave.org/dclarke/grub2/03_Jul_2007/grub2_002.jpg It worked well enough even if I did have problems with the menu list initially. I can't recall the last time I have looked at this or given it any thought. Perhaps I should take a glance there again as I was ( past tense ) doing some LFS work earlier this year on PowerPC and had diligently documented each and every build step. -- Dennis Clarke -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
SVN-20080403 : 5.6.1. Installation of Glibc failure
n.b. : this is a ppc machine and config.guess reports powerpc-unknown-linux-gnu I am attempting to follow the book and ran into a problem at 5.6.1 "Installation of Glibc". I tried twice with two different apporaches and both fail in a similar way. First attempt : [EMAIL PROTECTED]:/mnt/lfs/sources/build$ ls -lap total 32 drwxr-xr-x 8 lfs lfs 4096 Apr 2 23:54 ./ drwxrwxrwt 5 lfs root 4096 Apr 2 00:21 ../ drwxr-xr-x 15 lfs lfs 4096 Apr 2 00:31 binutils-2.18/ drwxr-xr-x 11 lfs lfs 4096 Apr 2 11:30 binutils-2.18-build/ drwxr-xr-x 25 lfs lfs 4096 Feb 1 13:45 gcc-4.2.3/ drwxr-xr-x 22 lfs lfs 4096 Apr 2 22:26 gcc-4.2.3-build/ drwxr-xr-x 66 lfs lfs 4096 Oct 18 07:22 glibc-2.7/ drwxr-xr-x 21 lfs lfs 4096 Apr 2 23:52 linux-2.6.24.2/ [EMAIL PROTECTED]:/mnt/lfs/sources/build$ mkdir glibc-2.7-build [EMAIL PROTECTED]:/mnt/lfs/sources/build$ cd glibc-2.7-build/ [EMAIL PROTECTED]:/mnt/lfs/sources/build/glibc-2.7-build$ echo "CFLAGS += -mpowerpc -mcpu=common -mno-altivec -m32 -mhard-float" > configparms [EMAIL PROTECTED]:/mnt/lfs/sources/build/glibc-2.7-build$ ../glibc-2.7/configure --prefix=/tools --disable-profile --enable-add-ons --enable-kernel=2.6.0 --with-binutils=/tools/bin --without-gd --with-headers=/tools/include --without-selinux checking build system type... powerpc-unknown-linux-gnu checking host system type... powerpc-unknown-linux-gnu configure: running configure fragment for add-on nptl checking sysdep dirs... sysdeps/powerpc/powerpc32/elf sysdeps/powerpc/elf sysdeps/unix/sysv/linux/powerpc/powerpc32/fpu sysdeps/powerpc/powerpc32/fpu nptl/sysdeps/unix/sysv/linux/powerpc/powerpc32 sysdeps/unix/sysv/linux/powerpc/powerpc32 nptl/sysdeps/unix/sysv/linux/powerpc sysdeps/unix/sysv/linux/powerpc sysdeps/ieee754/ldbl-128ibm sysdeps/ieee754/ldbl-opt nptl/sysdeps/unix/sysv/linux nptl/sysdeps/pthread sysdeps/pthread sysdeps/unix/sysv/linux sysdeps/gnu sysdeps/unix/common sysdeps/unix/mman sysdeps/unix/inet nptl/sysdeps/unix/sysv sysdeps/unix/sysv sysdeps/unix/powerpc nptl/sysdeps/unix sysdeps/unix sysdeps/posix sysdeps/powerpc/powerpc32 sysdeps/wordsize-32 sysdeps/powerpc/fpu nptl/sysdeps/powerpc sysdeps/powerpc sysdeps/ieee754/dbl-64 sysdeps/ieee754/flt-32 sysdeps/ieee754 sysdeps/generic/elf sysdeps/generic . . . etc etc etc . . . mawk: scripts/gen-sorted.awk: line 19: syntax error at or near ] mawk: scripts/gen-sorted.awk: line 19: runaway regular expression /, "", subd ... rm -f /mnt/lfs/sources/build/glibc-2.7-build/stamp.o; > /mnt/lfs/sources/build/glibc-2.7-build/stamp.o rm -f /mnt/lfs/sources/build/glibc-2.7-build/stamp.os; > /mnt/lfs/sources/build/glibc-2.7-build/stamp.os rm -f /mnt/lfs/sources/build/glibc-2.7-build/stamp.oS; > /mnt/lfs/sources/build/glibc-2.7-build/stamp.oS cd /mnt/lfs/sources/build/glibc-2.7-build && /tools/bin/ar cruv libc.a `cat stamp.o` : /mnt/lfs/sources/build/glibc-2.7-build/libc.a cd /mnt/lfs/sources/build/glibc-2.7-build && /tools/bin/ar cruv libc_pic.a `cat stamp.os` : /mnt/lfs/sources/build/glibc-2.7-build/libc_pic.a cd /mnt/lfs/sources/build/glibc-2.7-build && /tools/bin/ar cruv libc_nonshared.a `cat stamp.oS` : /mnt/lfs/sources/build/glibc-2.7-build/libc_nonshared.a make[1]: *** No rule to make target `/mnt/lfs/sources/build/glibc-2.7-build/Versions.all', needed by `/mnt/lfs/sources/build/glibc-2.7-build/abi-versions.h'. Stop. make[1]: Leaving directory `/mnt/lfs/sources/build/glibc-2.7' make: *** [all] Error 2 ATTEMPT NUMBER TWO - note the absence of CFLAGS in configparms [EMAIL PROTECTED]:/mnt/lfs/sources/build/glibc-2.7-build$ cd .. [EMAIL PROTECTED]:/mnt/lfs/sources/build$ rm -rf glibc-2.7-build/ [EMAIL PROTECTED]:/mnt/lfs/sources/build$ mkdir glibc-2.7-build [EMAIL PROTECTED]:/mnt/lfs/sources/build$ cd glibc-2.7-build [EMAIL PROTECTED]:/mnt/lfs/sources/build/glibc-2.7-build$ ../glibc-2.7/configure --prefix=/tools --disable-profile --enable-add-ons --enable-kernel=2.6.0 --with-binutils=/tools/bin --without-gd --with-headers=/tools/include --without-selinux checking build system type... powerpc-unknown-linux-gnu checking host system type... powerpc-unknown-linux-gnu configure: running configure fragment for add-on nptl checking sysdep dirs... sysdeps/powerpc/powerpc32/elf sysdeps/powerpc/elf sysdeps/unix/sysv/linux/powerpc/powerpc32/fpu sysdeps/powerpc/powerpc32/fpu nptl/sysdeps/unix/sysv/linux/powerpc/powerpc32 sysdeps/unix/sysv/linux/powerpc/powerpc32 nptl/sysdeps/unix/sysv/linux/powerpc sysdeps/unix/sysv/linux/powerpc sysdeps/ieee754/ldbl-128ibm sysdeps/ieee754/ldbl-opt nptl/sysdeps/unix/sysv/linux nptl/sysdeps/pthread sysdeps/pthread sysdeps/unix/sysv/linux sysdeps/gnu sysdeps/unix/common sysdeps/unix/mman sysdeps/unix/inet nptl/sysdeps/unix/sysv sysdeps/unix/sysv sysdeps/unix/powerpc nptl/sysdeps/unix sysdeps/unix sysdeps/posix sysdeps/powerpc/powerpc32 sysdeps/wordsize-32 sysdeps/powerpc/fpu nptl/sysdeps/powerpc sysdeps/powerpc sysdeps/ieee754/dbl-64 sysdeps/ieee754/flt-32 sysdeps/ieee754 sysdeps/generic/elf sysdeps/generic . . . etc etc
RFE for SVN-20080403
On page : http://www.linuxfromscratch.org/lfs/view/development/prologue/hostreqs.html There is no entry to check the version of perl in the script. Perhaps we could add : perl --version | head -2 | tail -1 thus : #!/bin/bash # Simple script to list version numbers of critical development tools bash --version | head -n1 | cut -d" " -f2-4 echo -n "Binutils: "; ld --version | head -n1 | cut -d" " -f3-4 bison --version | head -n1 bzip2 --version 2>&1 < /dev/null | head -n1 | cut -d" " -f1,6- echo -n "Coreutils: "; chown --version | head -n1 | cut -d")" -f2 diff --version | head -n1 find --version | head -n1 gawk --version | head -n1 gcc --version | head -n1 /lib/libc.so.6 | head -n1 | cut -d" " -f1-7 grep --version | head -n1 gzip --version | head -n1 cat /proc/version make --version | head -n1 patch --version | head -n1 perl --version | head -2 | tail -1 sed --version | head -n1 tar --version | head -n1 Output on this unit says : bash, version 3.1.17(1)-release Binutils: version 2.17 bison (GNU Bison) 2.3 bzip2, Version 1.0.3, 15-Feb-2005. Coreutils: 5.97 diff (GNU diffutils) 2.8.1 GNU find version 4.2.28 GNU Awk 3.1.5 gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) GNU C Library stable release version 2.3.6, grep (GNU grep) 2.5.1 gzip 1.3.12 Linux version 2.6.19-rc6 ([EMAIL PROTECTED]) (gcc version 4.1.2 20060901 (prerelease) (Debian 4.1.1-13)) #35 PREEMPT Mon Nov 27 20:48:16 CET 2006 GNU Make 3.81 patch 2.5.9 This is perl, v5.8.8 built for powerpc-linux-gnu-thread-multi GNU sed version 4.1.5 tar (GNU tar) 1.16 - Dennis Clarke -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: SVN-20080403 : 5.6.1. Installation of Glibc failure
> Dennis Clarke wrote: >> Both attempts seem to be failing in similar way. >> >> Not sure what direction to take here. >> >> Any thoughts ? > > Well the CFLAGS thing shouldn't be necessary on powerpc, so your second > approach was the better one. But then you hit this: > > 'mawk: scripts/gen-sorted.awk: line 19: regular expression compile failed > (bad class -- [], [^] or [) > /[^ > mawk: scripts/gen-sorted.awk: line 19: syntax error at or near ] > mawk: scripts/gen-sorted.awk: line 19: runaway regular expression /, "",' > > Interesting. What is the host system you're using? Debian etch > Also, instead of trying to adapt the development book to powerpc (I > assume that's what you're doing) Mostly I flail and make silly faces at my old DEC VT220 terminal here :-) I thought I was doing pretty well actually. Funny looking anyways. > you might want to try following the jh branch. Beautiful ! I will definately try that before going too far. > The last I checked it was working well on powerpc. It makes sure > that you get the right spec changes in gcc, etc. > http://linuxfromscratch.org/~jhuntwork/lfs-JH/ > > Looking forward to hearing more about your progress. > JH I see those letters JH there and I see them in the "jh branch". Somewhere in the back of my little brain I hear a dinging noise. It tells me that I am in good hands as well as a smaller, less thrilled voice that tells me to start over. I knew that this was an experimental process anyways and that part of learning and going forwards is falling over in the mud. Thank you ! I'm on top of that jh branch now and going letter by letter. Dennis Clarke -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: SVN-20080403 : 5.6.1. Installation of Glibc failure
> On Thu, Apr 3, 2008 at 2:47 PM, Jeremy Huntwork > <[EMAIL PROTECTED]> wrote: >> >> 'mawk: scripts/gen-sorted.awk: line 19: regular expression compile failed >> >> (bad class -- [], [^] or [) >> /[^ >> mawk: scripts/gen-sorted.awk: line 19: syntax error at or near ] >> mawk: scripts/gen-sorted.awk: line 19: runaway regular expression /, "",' >> >> Interesting. What is the host system you're using? > > I'm guessing it's Ubuntu. You really need gawk, not mawk. This came up > on libc-alpha a few months ago, but Drepper wouldn't budge on making > it more portable. Debian etch actually. I have received guidance from someone with initials JH and am moving forwards by starting over in the jh branch. Dennis -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: SVN-20080403 : 5.6.1. Installation of Glibc failure
> On Fri, Apr 4, 2008 at 7:28 AM, Alexander E. Patrakov > <[EMAIL PROTECTED]> wrote: >> >> Dan Nicholson wrote: >> > On Thu, Apr 3, 2008 at 8:15 PM, Alexander E. Patrakov >> > <[EMAIL PROTECTED]> wrote: >> >> Dan Nicholson wrote: >> >> > You really need gawk, not mawk. >> >> >> >> Then please add gawk and bison in Chapter 5 before binutils, to >> accomodate >> >> Debian-based LiveCDs and PCLinuxOS, respectively. >> > >> > The host requirements specify _Gawk_ 3.0. I really would prefer people >> > just check the host requirements instead of shoehorning temporary >> > packages at the beginning of the chapter. For an automated >> > environment, maybe, but it would just be clutter in the book. >> >> For a regular distro, I would agree. For a third-party LiveCD, I >> disagree. > > I still don't think instructions should be special for this situation. > If you chose a host that doesn't provide the necessary development > environment and doesn't provide the means to acquire the necessary > environment, then that probably wasn't the best choice. Instead, I'd > rather that the hostreqs page said "If you're host doesn't contain the > necessary requirements and doesn't provide a means to acquire them, > see the instructions in Ch. 6 as a guide to building them." > > Today it's bison and gawk. Maybe tomorrow it's make or flex. The > entire point of the Host System Requirements page is to establish a > baseline from where to start. I don't think it's wise to start adding > workarounds for that unless there's a really compelling reason. IMO, > these are compelling enough reasons. I think that the spirit of the Linux From Scratch project needs to be protected here. You should choose what you are trying to sell here, either the user can start with bare minimum or not. In my case I fell that all you need is some libs and a compiler and then you can build the rest yourself. Building make and bison and flex with a default install into /usr/local is trivial. There is no valid reason why the basic bare minimum requirements can not be dropped down to a compiler and maybe make. Nothing more is needed. The other alternative is that people just install Ubuntu or Debian or Fedora Core or Solaris and never look back again. What is Linux From "Scratch" all about? Linux From "Some Distro" ? Dennis -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
SVN-JH-20080403 5.7. Adjusting the Toolchain
I get different, and correct, output from the common sense check.
[EMAIL PROTECTED]:/mnt/lfs/sources/build$ mkdir foo
[EMAIL PROTECTED]:/mnt/lfs/sources/build$ cd foo
[EMAIL PROTECTED]:/mnt/lfs/sources/build/foo$ echo 'main(){}' > dummy.c
[EMAIL PROTECTED]:/mnt/lfs/sources/build/foo$ cc dummy.c
[EMAIL PROTECTED]:/mnt/lfs/sources/build/foo$ readelf -l a.out | grep ': /tools'
[Requesting program interpreter: /tools/lib/ld.so.1]
The above makes sense for a PowerPC system I think.
[EMAIL PROTECTED]:/mnt/lfs/sources/build/foo$
[EMAIL PROTECTED]:/mnt/lfs/sources/build/foo$ ls -l
total 16
-rwxr-xr-x 1 lfs lfs 11631 Apr 4 19:19 a.out
-rw-r--r-- 1 lfs lfs 9 Apr 4 19:18 dummy.c
[EMAIL PROTECTED]:/mnt/lfs/sources/build/foo$ file a.out
a.out: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV),
for GNU/Linux 2.6.0, dynamically linked (uses shared libs), for GNU/Linux
2.6.0, not stripped
[EMAIL PROTECTED]:/mnt/lfs/sources/build/foo$ ldd a.out
linux-vdso32.so.1 => (0x0010)
libc.so.6 => /tools/lib/libc.so.6 (0x0fe92000)
/tools/lib/ld.so.1 (0x3000)
[EMAIL PROTECTED]:/mnt/lfs/sources/build/foo$ cd ..
[EMAIL PROTECTED]:/mnt/lfs/sources/build$ rm -rf foo
It may be reasonable to include a line or two for RISC (PPC/ARM etc) based
people that may get different output from compiling that dummy.c code.
-
Dennis Clarke
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: SVN-20080403 : 5.6.1. Installation of Glibc failure
> Loren Foret wrote: >> More like linux from any distro. > But I think the point is that some distros now come with, for example, > dash as the default shell linked to /bin/sh, or as the OP apparently > found, mawk as the default AWK interpreter. If LFS is to become "more > than a book", it may be worthwhile to reconsider the "somewhat > arbitrary" host requirements, or at least point out that certain distros > may have the tools but they may not be invoked by default. Gentlemen, I really did not want to stir up a major debate. I am sorry if my little problems have caused and issue. I have the greatest respect for LFS and I really do see it as a true open source project where people can learn while doing. I did run into some little issues and if I were a tad more careful with that version check script then I never would have hit this. Maybe the question on the table here should be "what are the bare minimal requirements from which you can begin work?" I think that make and bison and flex etc etc can all be built if the user has at least GCC and some sort of running system. Am I wrong to think this way ? Dennis -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
RE: SVN-20080403 : 5.6.1. Installation of Glibc failure
> > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Dennis Clarke > Sent: Friday, April 04, 2008 8:22 PM > To: LFS Developers Mailinglist > Subject: Re: SVN-20080403 : 5.6.1. Installation of Glibc failure > > >> Loren Foret wrote: >>> More like linux from any distro. >> But I think the point is that some distros now come with, for example, >> dash as the default shell linked to /bin/sh, or as the OP apparently >> found, mawk as the default AWK interpreter. If LFS is to become "more >> than a book", it may be worthwhile to reconsider the "somewhat >> arbitrary" host requirements, or at least point out that certain distros >> may have the tools but they may not be invoked by default. > > Gentlemen, I really did not want to stir up a major debate. I am sorry > if my little problems have caused and issue. I have the greatest > respect for LFS and I really do see it as a true open source project > where people can learn while doing. > > I did run into some little issues and if I were a tad more careful > with that version check script then I never would have hit this. > > Maybe the question on the table here should be "what are the bare > minimal requirements from which you can begin work?" > > I think that make and bison and flex etc etc can all be built if > the user has at least GCC and some sort of running system. Am I > wrong to think this way ? > > Dennis > > > -- > > It's a good start... what you require at an absolute minimum is the "core > toolchain" > This being gcc, glibc, kernel headers, binutils. Those would get you > compiling but it would be a pain without some of the more obvious tools we > use a lot when compiling source. > those would be make and related. The minimum version for the tools you need > to "successfully" compile the core LFS system are in the book. For the > making of make bison and flex... I would imagine it could be done without a > version of make already installed but it would probably be a lot of work. > I would guess it realy depends on how you start the job. Is this a > cross-compile by chance? No Sir. This is all on PowerPC. Since I jumped into the jh branch all is going just swimmingly. Slow. But going fine. Dennis -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
RE: SVN-20080403 : 5.6.1. Installation of Glibc failure
>> to "successfully" compile the core LFS system are in the book. For the >> making of make bison and flex... I would imagine it could be done without > a >> version of make already installed but it would probably be a lot of work. >> I would guess it realy depends on how you start the job. Is this a >> cross-compile by chance? > > No Sir. This is all on PowerPC. Since I jumped into the jh branch all is > going just swimmingly. Slow. But going fine. > > Dennis > -- - > > Great :) Now it makes sense. I need to do a powerpc build pretty soon. Have > a PS3 that needs a good linux system on it :) Thus far everything "just works"(tm) and I am presently stuck watching the Chap 5 GCC pass2 testsuite run : === gcc Summary === # of expected passes42692 # of unexpected failures6 # of expected failures 115 # of unresolved testcases 1 # of untested testcases 28 # of unsupported tests 390 The binary looks good for gcc 4.2.3 , no surprises : [EMAIL PROTECTED]:~$ file /mnt/lfs/sources/build/gcc-4.2.3-build-pass2/gcc/xgcc /mnt/lfs/sources/build/gcc-4.2.3-build-pass2/gcc/xgcc: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), for GNU/Linux 2.6.0, dynamically linked (uses shared libs), for GNU/Linux 2.6.0, not stripped [EMAIL PROTECTED]:~$ ldd /mnt/lfs/sources/build/gcc-4.2.3-build-pass2/gcc/xgcc linux-vdso32.so.1 => (0x0010) libc.so.6 => /tools/lib/libc.so.6 (0x0fe92000) /tools/lib/ld.so.1 (0x3000) [EMAIL PROTECTED]:~$ /mnt/lfs/sources/build/gcc-4.2.3-build-pass2/gcc/xgcc -v Reading specs from /tools/lib/gcc/powerpc-unknown-linux-gnu/4.2.3/specs Target: powerpc-unknown-linux-gnu Configured with: ../gcc-4.2.3/configure --prefix=/tools --with-local-prefix=/tools --enable-clocale=gnu --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-languages=c,c++ --disable-libstdcxx-pch --disable-multilib Thread model: posix gcc version 4.2.3 I'll post any interesting progress reports as they occur. Dennis -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: SVN-20080403 : 5.6.1. Installation of Glibc failure
> Dennis Clarke wrote: > >>> No Sir. This is all on PowerPC. > > Please take this thread to lfs-support. Why ? I don't think this is a support issue at all. More of a "could LFS be more generic and open to other architectures" sort of thing. Since leaping over to the JH-20080403 version I am doing very well now. If ( SVN-JH-20080403 is a modification of LFS ) then perhaps some changes in SVN-JH-20080403 should be brought to the LFS mainline. Just a thought. Dennis -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS size and hardware requirements
> Alexander E. Patrakov wrote: >> No, learning must be gradual, the reader must see a trouble-free >> book first and _then_ experiment. >> > Learning is gradual, but is almost never trouble-free. A child learning > to walk stumbles countless times before achieving balance and poise. I > have stumbled quite a bit with LFS and even used an old Pentium machine > as a learning platform. If someone can build LFS in 8-12 hours, > perfectly and in a single session the very first time, it seems to me > that either they're already experts or very lucky and haven't learned > much from the experience. I am very very slowly working my way through the JH branch with a very very small PowerPC based machine. http://www.blastwave.org/dclarke/efika/efika_002_m.jpg This little thing has 128 MB of memory and a 5400 rpm laptop type Seagate drive on it. I am in chapter 5, well I just finished chapter 5 actually. I am connected to it via a serial line console and I have a DEC VT220 Terminal vesta:~# uptime 12:25:24 up 11 days, 1:02, 1 user, load average: 0.00, 0.00, 0.00 vesta:~# who root ttyPSC0 2008-04-07 17:56 vesta:~# vesta:~# cat /proc/cpuinfo processor : 0 cpu : G2_LE clock : 396.00MHz revision: 1.4 (pvr 8082 2014) bogomips: 65.53 timebase: 3300 platform: Efika machine : EFIKA5K2 CHRP PowerPC System revision: 2B3 vendor : bplan vesta:~# df -h $LFS FilesystemSize Used Avail Use% Mounted on /dev/sda3 3.9G 3.1G 667M 83% /mnt/lfs vesta:~# The process has been, what word shall I use? Slow? Steady is what it has been and because of the serial console connection I have recorded the full session of each stage into a log file. bash-3.2$ ls lfs_log chap5_adjust_toolchain chap5_gettext-0.17 chap5_bash-3.2 chap5_glibc_2.7 chap5_binutils-2.18 chap5_grep-2.5.3 chap5_binutils-2.18-pass2 chap5_gzip-1.3.12 chap5_bzip2-1.0.5 chap5_linux-2.6.24.4 chap5_change_ownership chap5_make-3.81 chap5_coreutils-6.10chap5_ncurses-5.6 chap5_dejagnu-1.4.4 chap5_patch-2.5.4 chap5_diffutils-2.8.1 chap5_perl-5.8.8 chap5_e2fsprogs-1.40.6 chap5_sed-4.1.5 chap5_findutils-4.2.33 chap5_tar-1.19 chap5_gawk-3.1.6chap5_tcl8.4.18 chap5_gcc-4.2.3 chap5_texinfo-4.11 chap5_gcc_4.2.3_pass2 chap5_util-linux-ng-2.13.1 I can tell you that the second build of GCC was about twelve hours. The testsuite was another twelve to sixteen. I don't know which and I may be guessing. Everything works as is should and I am about to venture into Chapter 6. As a personal note, I can tell you that I do have access to some really screaming fast hardware but where is the fun in that? That is like showing up at a community racetrack with a Maserati MC12 and it will be fancy and slick for some people to look at but no one is really impressed. If you can push an old 1976 Ford Pickup truck over the quarter mile un less than 12 seconds then you have done something interesting there. Perhaps even bizarre. I am doing my first LFS build in five or six years and I chose this little ppc unit to do it with. Because of what LFS is really about, to me, is learning and seeing each piece along the journey. Dennis Clarke -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
SVN-JH-20080403 : 6.9. Glibc-2.7 - more than a few errors
I have taken a run at this twice and am not entirely sure if the situation is acceptable or not. I build glibc as detailed and then run "make -k check " with output being dumped via tee into glibc-check-log. The make -k check ends with these lines : make[1]: Target `check' not remade because of errors. make[1]: Leaving directory `/sources/build/glibc-2.7' make: *** [check] Error 2 The errors seen are thus : root:/sources/build/glibc-build# grep Error glibc-check-log make[2]: *** [/sources/build/glibc-build/math/test-ldouble.out] Error 1 make[2]: *** [/sources/build/glibc-build/math/test-ildoubl.out] Error 1 make[1]: *** [math/tests] Error 2 make[2]: *** [/sources/build/glibc-build/string/stratcliff.out] Error 1 make[1]: *** [string/tests] Error 2 make[2]: *** [/sources/build/glibc-build/wcsmbs/wcsatcliff.out] Error 1 make[1]: *** [wcsmbs/tests] Error 2 make[2]: [/sources/build/glibc-build/posix/annexc.out] Error 1 (ignored) make[2]: *** [/sources/build/glibc-build/crypt/sha256c-test.out] Error 1 make[2]: *** [/sources/build/glibc-build/crypt/sha512c-test.out] Error 1 make[1]: *** [crypt/tests] Error 2 make[2]: *** [/sources/build/glibc-build/elf/check-localplt.out] Error 1 make[1]: *** [elf/tests] Error 2 make: *** [check] Error 2 root:/sources/build/glibc-build# Other than the "posix/annexc.out" error that was predicted I am somewhat less than thrilled at the math errors related to long doubles, the errors for crypto functions and then there are errors related to a string function. Should I be worried ? Dennis -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: SVN-JH-20080403 : 6.9. Glibc-2.7 - more than a few errors
> Dennis Clarke wrote these words on 04/18/08 13:11 CST: >> I have taken a run at this twice and am not entirely sure if the situation >> is acceptable or not. > > I cannot answer that either. You've received more errors than I > have while building in several different environments. darn :-( I don't really have any recourse here. I followed every step carefully and yet here I am. >> Should I be worried ? > > I'm really not qualified to answer that. However, in the spirit > of trying to be helpful, here is information from 3 different > recent builds of Glibc: > > First, here's results from using CLFS techniques for a multilib > build (note that I'm using GCC-4.2.2 during these builds) > > [EMAIL PROTECTED]:/media/hdb1/build/Installed$ grep Error glibc*/check.log > glibc-2.7-32bit/check.log:make[2]: *** > [/build/glibc-build/math/test-double.out] Error 1 > glibc-2.7-32bit/check.log:make[1]: *** [math/tests] Error 2 > glibc-2.7-32bit/check.log:make[2]: [/build/glibc-build/posix/annexc.out] > Error 1 (ignored) > glibc-2.7-32bit/check.log:make: *** [check] Error 2 > glibc-2.7-64bit/check.log:make[2]: [/build/glibc-build/posix/annexc.out] > Error 1 (ignored) that looks better than what I have. > Now a build from regular LFS using a 32bit Athlon: > > [EMAIL PROTECTED]: /mnt/rml2/home/rml/build > grep Error > /mnt/rml5/build/Installed/glibc*/check.log > make[2]: [/build/glibc-build/posix/annexc.out] Error 1 (ignored) > > So, bottom line for me is I don't see any errors other than the > math/test-double error in a 32bit multilib build. Both the 64bit > multilib and regular LFS (not JH branch) don't get any errors. I think that I had better wait to see whom else chimes in. Perhaps there is some magic incantation that will resolve all this issues. Or not :-\ In either case I will sit tight and wait for the great oracle on the mountain to speak. Unless you are he. In which case I'm really in trouble eh? - Dennis Clarke -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: SVN-JH-20080403 : 6.9. Glibc-2.7 - more than a few errors
> On Fri, Apr 18, 2008 at 02:53:27PM -0400, Dennis Clarke wrote: >> >> > Dennis Clarke wrote these words on 04/18/08 13:11 CST: >> >> I have taken a run at this twice and am not entirely sure if the >> situation >> >> is acceptable or not. >> > >> > I cannot answer that either. You've received more errors than I >> > have while building in several different environments. >> >> darn :-( >> > My most recent ppc build (clfs, book dated 20080212) with > glibc-2.7 had the following fail (1.4GHz G4): > > math/test-ldouble.out > math/test-ildoubl.out > crypt/sha512c-test.out > elf/check-localplt.out Some of the above looks familiar here. OKay, I feel better only because someone else with PPC has seen similar errors and the "misery loves company" approach to software engineering is, sometimes, the only comfort we have left. > Generally, once you change arches, different things fail in the > toolchain tests. odd .. but true. C'est la vie. > I don't have any problems with the resulting system (well, finding > a working version of the xorg radeon driver in the 6.7 series was > interesting, and gave decidedly unusual lockups, but > xf86-video-ati-6.8.0 works fine (and everything bar gutenprint seems > ok)). Thankfully this unit is all about being embedded and it needs only a functional serial console and a few other things.[1] > You must be using --enable-kernel=2.6.0 (or, at least, a value less yes > than 2.6.22), otherwise the compile would have failed early on - the > old clfs -branch_update-1 patch fixed that, but broke builds with > values < 2.6.22 in that switch. That is just an example of the > sorts of things which can change on different arches. I think that I need to make the sign of the cross, say three Hail Mary's and then plow forwards. Other options include the sacrifice of a small animal and things are not that dismal. Yet. :-\ Dennis [1] I'll work up a fresh port of GRUB2 to ppc for this at some point. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: SVN-JH-20080403 : 6.9. Glibc-2.7 - more than a few errors
> Randy McMurchy wrote: >> So, bottom line for me is I don't see any errors other than the >> math/test-double error in a 32bit multilib build. Both the 64bit >> multilib and regular LFS (not JH branch) don't get any errors. > > Not really the bottom line (yet). Dennis is working on a PowerPC arch. > Or, at least, the last I checked he was. Yes Sir. Same machine and I am still working through the JH branch of the LFS process. I did take a break from it for a few days but in general the unit remains powered on and connected via serial console cable. [EMAIL PROTECTED]:~$ cat /proc/cpuinfo processor : 0 cpu : G2_LE clock : 396.00MHz revision: 1.4 (pvr 8082 2014) bogomips: 65.53 timebase: 3300 platform: Efika machine : EFIKA5K2 CHRP PowerPC System revision: 2B3 vendor : bplan [EMAIL PROTECTED]:~$ uptime 2:22pm up 18 days 2:59, 2 users, load average: 1.25, 1.14, 1.10 [EMAIL PROTECTED]:~$ Right now it is working on GCC in Chap 6. > I know that there are different expectations for what the tests will > produce on PowerPC, but as to what is acceptable, I haven't had the time > to investigate since the original test I ran several months back. Ken do > you have any test data for PowerPC on a recent build? I think that there is a lack of data here. I could begin to hunt down the long double issues and perhaps there is a problem with the IEEE754 long double implementation. A signaling NaN or some such that is not trapped and handled correctly. Tough to say and it would take *considerable* work to find. Since I am not about to break out Metrowerks Codewarrior JTAG debugger ( Freescale? ) to single step through this and watch for FPU activity I am going to face east , pray for forgiveness over sins committed and install with fingers crossed. :-) However, this is glibc and not my favorite video game. It deserves more than a nod and thus I'll drop a note to David Woodhouse[1] ( whom I have spoken with before ) and see if perhaps some PPC intelligence can be brought to bear on the issue. It wouldn't be the first time that people managed to track down the offense and then pushed a patch upstream. Dennis [1] and he does have a flair for the PowerPC see : http://lkml.org/lkml/2007/5/24/127 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: SVN-JH-20080403 : 6.9. Glibc-2.7 - more than a few errors
> Randy McMurchy wrote: >> So, bottom line for me is I don't see any errors other than the >> math/test-double error in a 32bit multilib build. Both the 64bit >> multilib and regular LFS (not JH branch) don't get any errors. > > Not really the bottom line (yet). Dennis is working on a PowerPC arch. > Or, at least, the last I checked he was. Well the situation seems to be degrading slowly. Thus far in Chap6 I have the following from the GCC testsuite : === gcc Summary === # of expected passes42691 # of unexpected failures6 # of expected failures 115 # of unresolved testcases 1 # of untested testcases 28 # of unsupported tests 390 The FAILures seen were : FAIL: gcc.c-torture/compile/20001226-1.c -O2 (test for excess errors) FAIL: gcc.c-torture/compile/20001226-1.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.c-torture/compile/20001226-1.c -O3 -g (test for excess errors) FAIL: gcc.c-torture/compile/20001226-1.c -Os (test for excess errors) FAIL: gcc.dg/tree-ssa/loop-19.c scan-tree-dump-times MEM.(base: &|symbol: )a, 2 FAIL: gcc.dg/tree-ssa/loop-19.c scan-tree-dump-times MEM.(base: &|symbol: )c, 2 The testsuite is still running and I expect that will continue for another ten hours or so. Again I have no baseline with which to compare and a generaly sinking feeling about my LFS end result, if I ever get there. If anyone has words of encouragement .. now would be a good time :-) Dennis -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: SVN-JH-20080403 : 6.9. Glibc-2.7 - more than a few errors
> Dennis Clarke wrote these words on 04/19/08 17:29 CST: > >> If anyone has words of encouragement .. now would be a good time :-) > > 6 errors out of 42,000 tests ain't sh*t. Drive on, brother. Boot it > up and see what happens. :-) Should I be yelling "yeehaw" and waving a cowboy hat at the same time? Dennis Clarke ps: please see : Dr. Strangelove or: How I Learned to Stop Worrying and Love the Bomb http://www.imdb.com/title/tt0057012/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: SVN-JH-20080403 : 6.9. Glibc-2.7 - more than a few errors
> Dennis Clarke wrote: >> If anyone has words of encouragement .. now would be a good time :-) > > Yeah, what Randy said. :) Anyway, yours is the type of testing, interest > and feedback we need to keep this project alive and moving forward, so > keep it coming. I know it's a bear to try to sort out all the failure > issues, but any (little) thing that can be done to weed out bugs or test > failures is indeed helpful. I think that I will press on and try not to hit perfection. I'll strive for some degree of functionality with a few device drivers and then be happy. I fully expect that things will work out fine in the end. I have not yet had to look at any assembly .. so we are doing well. > Out of curiosity (not that it should matter by the time you reach > chapter 6) what is the host system you're using for the build? Sorry if > you mentioned it already and I missed it. It is called an EFIKA. Probably better to call it EFIKA rev 1.0 Here comes the gory details. 1) Here is the complete system. The hard drive is removed so you can see the system board : http://www.blastwave.org/dclarke/efika/efika_004_m.jpg 2) A *nearly* mil-spec 18 gauge steel case was designed which would act as both protection as well as a natural heat sink. http://www.blastwave.org/dclarke/efika/prototype_000.png 3) One of the first units off the assembly line : http://www.blastwave.org/dclarke/efika/prototype_002.png 4) Really early .. beta type design : http://www.blastwave.org/dclarke/efika/prototype_003.jpg http://www.blastwave.org/dclarke/efika/prototype_004.jpg What I have here on my desk is the black steel case design with a Seagate drive on it. The firmware is OpenFirmware and the boot loader is my own port of GRUB2. The processor is a Freescale MPC5200B Power Architecture System-on-Chip design with 128MB of RAM. Here is a little movie of people doing nifty stuff with the early prototypes : http://www.pegasosppc.com/movies/efika_de.mp4 There is a rev 2 in the works, or so I hear. Faster proc and more memory. I expect that the original design objective was to have a deive with no moving parts that could run a modern OS ( Linux or OpenSolaris ) and so low power that it could run for *days* on a car battery with virtually no heat being produced. Pretty cool device huh ? I have installed the ATI Radeon graphics card in the past and used this as a desktop. It works just fine if you are willing to make concessions for both speed and disk IO rates. In bulk I would expect that the unit could get down to $99 per but that would require a really large volume. Anyways, it is damn fine technology in an itty bitty space. Dennis -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: SVN-JH-20080403 : 6.9. Glibc-2.7 - more than a few errors
> Dennis Clarke wrote: >> If anyone has words of encouragement .. now would be a good time :-) > > Yeah, what Randy said. :) Anyway, yours is the type of testing, interest > and feedback we need to keep this project alive and moving forward, so > keep it coming. I know it's a bear to try to sort out all the failure > issues, but any (little) thing that can be done to weed out bugs or test > failures is indeed helpful. Well GCC 4.2.3 just finished the testsuite and I have installed it. It looks to be not bad : root:/sources/build/gcc-4.2.3-build# ../gcc-4.2.3/contrib/test_summary cat <<'EOF' | LAST_UPDATED: Obtained from SVN: tags/gcc_4_2_3_release revision 132046 Native configuration is powerpc-unknown-linux-gnu === g++ tests === Running target unix === g++ Summary === # of expected passes13655 # of expected failures 67 # of unsupported tests 104 /sources/build/gcc-4.2.3-build/gcc/testsuite/g++/../../g++ version 4.2.3 === gcc tests === Running target unix WARNING: program timed out. FAIL: gcc.c-torture/compile/20001226-1.c -O2 (test for excess errors) WARNING: program timed out. FAIL: gcc.c-torture/compile/20001226-1.c -O3 -fomit-frame-pointer (test for excess errors) WARNING: program timed out. FAIL: gcc.c-torture/compile/20001226-1.c -O3 -g (test for excess errors) WARNING: program timed out. FAIL: gcc.c-torture/compile/20001226-1.c -Os (test for excess errors) UNRESOLVED: gcc.c-torture/execute/mayalias-2.c execution, -O3 -g FAIL: gcc.dg/tree-ssa/loop-19.c scan-tree-dump-times MEM.(base: &|symbol: )a, 2 FAIL: gcc.dg/tree-ssa/loop-19.c scan-tree-dump-times MEM.(base: &|symbol: )c, 2 ERROR: tcl error sourcing /sources/build/gcc-4.2.3/gcc/testsuite/gcc.misc-tests/linkage.exp. ERROR: couldn't execute "file": no such file or directory === gcc Summary === # of expected passes42691 # of unexpected failures6 # of expected failures 115 # of unresolved testcases 1 # of untested testcases 28 # of unsupported tests 390 /sources/build/gcc-4.2.3-build/gcc/xgcc version 4.2.3 === libgomp tests === Running target unix === libgomp Summary === # of expected passes496 === libmudflap tests === Running target unix === libmudflap Summary === # of expected passes1814 === libstdc++ tests === Running target unix XPASS: 26_numerics/cmath/c99_classification_macros_c.cc (test for excess errors) WARNING: program timed out. FAIL: ext/pb_ds/regression/hash_data_map_rand.cc (test for excess errors) WARNING: ext/pb_ds/regression/hash_data_map_rand.cc compilation failed to produce executable WARNING: program timed out. FAIL: ext/pb_ds/regression/tree_data_map_rand.cc (test for excess errors) WARNING: ext/pb_ds/regression/tree_data_map_rand.cc compilation failed to produce executable WARNING: program timed out. FAIL: ext/pb_ds/regression/tree_no_data_map_rand.cc (test for excess errors) WARNING: ext/pb_ds/regression/tree_no_data_map_rand.cc compilation failed to produce executable === libstdc++ Summary === # of expected passes3846 # of unexpected failures3 # of unexpected successes 1 # of expected failures 15 # of unsupported tests 316 Compiler version: 4.2.3 Platform: powerpc-unknown-linux-gnu configure flags: --prefix=/usr --libexecdir=/usr/lib --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --disable-multilib --disable-bootstrap --enable-languages=c,c++ EOF Mail -s "Results for 4.2.3 testsuite on powerpc-unknown-linux-gnu" [EMAIL PROTECTED] && mv /sources/build/gcc-4.2.3-build/./gcc/testsuite/g++/g++.sum /sources/build/gcc-4.2.3-build/./gcc/testsuite/g++/g++.sum.sent && mv /sources/build/gcc-4.2.3-build/./gcc/testsuite/gcc/gcc.sum /sources/build/gcc-4.2.3-build/./gcc/testsuite/gcc/gcc.sum.sent && mv /sources/build/gcc-4.2.3-build/./powerpc-unknown-linux-gnu/libgomp/testsuite/libgomp.sum /sources/build/gcc-4.2.3-build/./powerpc-unknown-linux-gnu/libgomp/testsuite/libgomp.sum.sent && mv /sources/build/gcc-4.2.3-build/./powerpc-unknown-linux-gnu/libmudflap/testsuite/libmudflap.sum /sources/build/gcc-4.2.3-build/./powerpc-unknown-linux-gnu/libmudflap/testsuite/libmudflap.sum.sent && mv /sources/build/gcc-4.2.3-build/./powerpc-unknown-linux-gnu/libstdc++-v3/testsuite/libstdc++.sum /sources/build/gcc-4.2.3-build/./powerpc-unknown-linux-gnu/libstdc++-v3/testsuite/libstdc++.sum.sent && mv /sources/build/gcc-4.2.3-build/./gcc/testsuite/g++/g++.log /sources/build/gcc-4.2.3-build/./gcc/testsuite/g++/g++.log.sent && mv /sources/build/gcc-4.2.3-build/./gcc/testsuite/gcc/gcc.log /sources/build/gcc-4.2.3-build/./gcc/testsuite/gcc/g
Re: LFS Roadmap (Was: Re: As promised: LFS compilation summary)
On Thu, May 8, 2008 at 10:35 PM, Jeremy Huntwork <[EMAIL PROTECTED]> wrote: > Bruce Dubbs wrote: > > In any case, I don't see a reason that there won't be a LFS 6.4 or 7.0 > release > > sometime this summer. > > At the current rate, if we do LFS 7.0 this summer it would have to be > sans package manager. > > However, x86_64 support (and PowerPC, for that matter) is pretty much > ready to drop in. The only thing missing is the change of boot loader > section and adjustments to the kernel page. It's really just a matter of > forcing myself to sit down and do it. I've been getting side tracked by > a lot of other things. Sorry to drop in. I just wanted you to know that I was still out here working on this little embedded PPC device and that I was getting to the boot loader issue .. eventually. Just FYI. Dennis Clarke -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS Roadmap (Was: Re: As promised: LFS compilation summary)
On Fri, May 9, 2008 at 1:35 AM, Jeremy Huntwork <[EMAIL PROTECTED]> wrote: > Dennis Clarke wrote: > > Sorry to drop in. I just wanted you to know that I was still out here > > working on this little embedded PPC device and that I was getting to > > the boot loader issue .. eventually. > > Don't apologize. :) Dropping in is welcome. you know .. I really like the atmosphere in the LFS project. Such a nice bunch of people. > > Just FYI. > > Thanks for the reminder, Dennis. I'll leave a spot for your input, then. > In the meantime, I'll try to get the framework for the boot loaders > section in place. I'll be getting to it shortly .. like this week or so. Real Soon Now (tm) Looks like I'm still kinda partial to GRUB2 if you see value in that. Dennis -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS Roadmap (Was: Re: As promised: LFS compilation summary)
On Fri, May 9, 2008 at 10:05 PM, Dan Nicholson <[EMAIL PROTECTED]> wrote: > On Thu, May 8, 2008 at 6:52 PM, Jeremy Huntwork > <[EMAIL PROTECTED]> wrote: > > > > I think that the prevailing attitude here is rather anti GRUB2. Mostly > > because development on it seems to focus on items perceived as useless > > and bloat for a boot loader. > > I haven't piped in on this at all, but I'd just like to say that I > really, really want to be pro-grub2. I periodically peruse the > grub-devel archives hoping to see that a 2.0 release is imminent. I > find it ridiculous that there's no currently supported grub. But, > anyway, I'm still x86 all the time, so grub-0.9.7 is good enough for > me. I'll be curious how this plays out, though. Well, I have done this before with PowerPC and so I hope that it will be a case of "nothing new to see here" and everything just works. Dennis -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
SVN-JH-20080423 : Step 8.3. Linux-2.6.24.4
Things were going well here with PowerPC based machine. BOOTAS arch/powerpc/boot/fixed-head.o BOOTCC arch/powerpc/boot/ep88xc.o BOOTCC arch/powerpc/boot/cuboot-hpc2.o BOOTCC arch/powerpc/boot/empty.o HOSTCC arch/powerpc/boot/addnote HOSTCC arch/powerpc/boot/hack-coff HOSTCC arch/powerpc/boot/mktree WRAParch/powerpc/boot/zImage.chrp WRAParch/powerpc/boot/cuImage.52xx /sources/build/linux-2.6.24.4/arch/powerpc/boot/wrapper: line 257: mkimage: command not found make[1]: *** [arch/powerpc/boot/cuImage.52xx] Error 127 make: *** [zImage] Error 2 root:/sources/build/linux-2.6.24.4# The problem is the FreeScale 52XX processor target and I'm looking into it to see what the issue may be and I'll let you know what I find. Dennis Clarke -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: GMP and MPFR
> Philipp Christian Loewner wrote: >> From what I understand about it, building GMP and MPFR as separate >> packages is the preferred method, but the bootstrap build will fail >> to locate these programs in the /tools directory in the first stage. > > Hmmm. I read through that thread already, but I didn't see any reasoning > for why the current approach. I don't know why installing them as > separate packages is preferable. Some things to consider: > > * Only GCC needs them. > > * GCC has a mechanism built in to build them and use them the way it > needs to. If we would just let it build them, then there's that much > less possibility of breakage due to misconfiguration. > > * I don't know if I particularly want to have two extra libs installed > in my final (or temporary) system that I will either rarely or never use > otherwise. I've used gpm separately before, but usually, in that > instance if I need it, I'm totally happy getting it and installing it > then. Sorry to drop in after being away so long. This topic is near and dear to my heart and I had to speak up. The libgmp and libmpfr libs are quite valuable to the people in the scientific or mathematics world and I, for one, use them a lot. While GCC needs them as part of the bootstrap process and then LFS has no other need I would submit to you the idea that these two libs are of great value to a number of technical users. Also, there are other software packages which the user may want later on that depend on either gmp or mpfr ( or both ) such as PHP 5 - GnuMP Extensions and ClamAV antivirus software. I say to you that having the gmp and mpfr packages as separate items/packages is of value and with so little overhead required to build them it would perhaps be best to leave them in the LFS process as is. Dennis Clarke -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
