Re: Remarks on LFS-6.2

2007-03-26 Thread Ken Moffat
On Sun, Mar 25, 2007 at 09:23:39PM -0500, Bruce Dubbs wrote: > > Some benchmarks against a 32-bit build would be interesting. My > understanding is that 64-bit systems have larger binaries, use more ram, > and are slower the equivalent 32-bit systems unless you are doing some > fairly serious nu

Re: Remarks on LFS-6.2

2007-03-25 Thread Bruce Dubbs
Fix wrote: > On 3/26/07, Bruce Dubbs <[EMAIL PROTECTED]> wrote: >> Some benchmarks against a 32-bit build would be interesting. My >> understanding is that 64-bit systems have larger binaries, use more ram, >> and are slower the equivalent 32-bit systems unless you are doing some >> fairly seriou

Re: Remarks on LFS-6.2

2007-03-25 Thread Fix
On 3/26/07, Bruce Dubbs <[EMAIL PROTECTED]> wrote: > > Some benchmarks against a 32-bit build would be interesting. My > understanding is that 64-bit systems have larger binaries, use more ram, > and are slower the equivalent 32-bit systems unless you are doing some > fairly serious number crunch

Re: Remarks on LFS-6.2

2007-03-25 Thread Bruce Dubbs
Fix wrote: > Nevertheless, now I've finished building a __pure__ 64-bit *LFS > without use of the cross compilation, with slight deviations from the > book. All the libraries now are 64-bit and they're placed in > {,/usr}/lib instead of {,/usr}/lib64. In order to achieve this, six > different patc

Re: Remarks on LFS-6.2

2007-03-25 Thread Fix
On 3/21/07, Matthew Burgess <[EMAIL PROTECTED]> wrote: > I'd be interested if you can reproduce your tens of failures using jhalfs, if > only to rule out a) mistakes in any build scripts you might be using and/or > b) mistakes made when copying/pasting/typing the commands from the book. > scripts

Re: Remarks on LFS-6.2

2007-03-20 Thread Matthew Burgess
On Tuesday 20 March 2007 02:26, Fix wrote: > So that I'm waiting for anyone else to confirm or to reject the report. Using jhalfs r3335 to complete a build of LFS SVN-20070319 on an i686 box, only annexc and tst-cancel1.out fail for me, and test-installation.pl reports success too. While the cu

Re: Remarks on LFS-6.2

2007-03-19 Thread Fix
On 3/19/07, Chris Staub <[EMAIL PROTECTED]> wrote: > > It's the test that's run at the end of "make install". Well, I'd run "make -k check 2>&1 | tee glibc-build-check" just after "make install", and got a few failures only (including posix/annexc and a couple of tests failed due to the absence of

Re: Remarks on LFS-6.2

2007-03-18 Thread Chris Staub
Fix wrote: > > About what a test are you saying, that which is execute after (in the > process of) "make install", or about bunch of the small test programs > that are executed by "make check"? I mean second, and at the time they > are executing NO libraries are installed in /lib. If, naturally, y

Re: Remarks on LFS-6.2

2007-03-18 Thread Fix
On 3/19/07, Chris Staub <[EMAIL PROTECTED]> wrote: > The command in the book should change it so that the test uses the > newly-installed libraries in /lib. About what a test are you saying, that which is execute after (in the process of) "make install", or about bunch of the small test programs

Re: Remarks on LFS-6.2

2007-03-18 Thread Fix
On 3/19/07, Chris Staub <[EMAIL PROTECTED]> wrote: > Well, as I mentioned before, it should never have been created anyway. > The actual problem needs to be fixed, not simply worked around with a > symlink. For sure. I've said "a temporary" workaround. Fix -- http://linuxfromscratch.org/mailman

Re: Remarks on LFS-6.2

2007-03-18 Thread Chris Staub
Fix wrote: > On 3/19/07, Chris Staub <[EMAIL PROTECTED]> wrote: >> LFS does not work for 64-bit systems. > > Yes, I know. But on a i386 system, these tests should be linked > against /tools/lib/ld-linux.so.2 or against just compiled new linker > that resides somewhere in glibc-build directory? >

Re: Remarks on LFS-6.2

2007-03-18 Thread Fix
On 3/19/07, Chris Staub <[EMAIL PROTECTED]> wrote: > > > LFS does not work for 64-bit systems. Yes, I know. But on a i386 system, these tests should be linked against /tools/lib/ld-linux.so.2 or against just compiled new linker that resides somewhere in glibc-build directory? Fix -- http://linux

Re: Remarks on LFS-6.2

2007-03-18 Thread Chris Staub
Fix wrote: > On 3/19/07, Chris Staub <[EMAIL PROTECTED]> wrote: > >> No, the "test" it is referring to is done at the end of "make install". >> It even specifies this at the beginning of the text you just >> copied-and-pasted from the book. If you *are* getting a large number of >> testsuite error

Re: Remarks on LFS-6.2

2007-03-18 Thread Fix
On 3/19/07, Chris Staub <[EMAIL PROTECTED]> wrote: > No, the "test" it is referring to is done at the end of "make install". > It even specifies this at the beginning of the text you just > copied-and-pasted from the book. If you *are* getting a large number of > testsuite errors, something else i

Re: Remarks on LFS-6.2

2007-03-18 Thread Chris Staub
Chris Staub wrote: >> Running "make install" in section 6.9.1 I have discovered that perl >> binary installed in /tools/bin tries to locate its >> extensions in /usr/local/* directories, however they were installed >> in /tools/share/perl5/*. Before entering the chroot >> environment

Re: Remarks on LFS-6.2

2007-03-18 Thread Chris Staub
Fix wrote: > And two remarks on the LFS-6.2. > > 1. Section 6.9.1. Installation of Glibc > > [QUOTE] > When running make install, a script called test-installation.pl > performs a small sanity test on our newly installed Glibc. However, > because our toolchain sti

Remarks on LFS-6.2

2007-03-18 Thread Fix
And two remarks on the LFS-6.2. 1. Section 6.9.1. Installation of Glibc [QUOTE] When running make install, a script called test-installation.pl performs a small sanity test on our newly installed Glibc. However, because our toolchain still points to the /t