On November 30, 2008 10:29:25 pm Stealth wrote:
> Is there anything on this page (book 6.3 ch 5.2) that needs to be
> done before going to 5.3 to follow the binutils build instructions?
Everyone has been amazingly patient with your criticism of the book.
Please take the time to re-read the follow
On a previous page (book 6.3 ch 5.1) This was mentioned:
Important
Before issuing the build instructions for a package, the package
should be unpacked as user lfs, and a cd into the created directory
should be performed. The build instructions assume that the bash
shell is in use.
This is fou
On Monday 01 December 2008 01:40:22 am Chris Staub wrote:
> Stealth wrote:
> > Is there anything on this page (book 6.3 ch 5.2) that needs to
> > be done before going to 5.3 to follow the binutils build
> > instructions?
>
> As it says at the beginning of that page, it's just a summary of
> how eve
Stealth wrote:
> Is there anything on this page (book 6.3 ch 5.2) that needs to be
> done before going to 5.3 to follow the binutils build instructions?
As it says at the beginning of that page, it's just a summary of how
everything in the rest of the book will be done, and something that
you'r
Is there anything on this page (book 6.3 ch 5.2) that needs to be
done before going to 5.3 to follow the binutils build instructions?
This goes back to the confusion I have talked about before in other
posts to this list. I cannot tell if I am actually supposed to do
anything with any of this i
On Sunday 30 November 2008 07:57:28 pm DJ Lucas wrote:
> Stealth wrote:
> > I am following the book as it is written. The only exception
> > was I used kernel 2.6.27.7 .
>
> This is not good, though not likely the cause of the problem you
> are seeing. You should be using 2.6.22.19. The latest 2.6
On Sun, Nov 30, 2008 at 06:57:28PM -0600, DJ Lucas wrote:
> No. I never meant to imply that there was _missing _information, 'out
> of sync' information, or missing instructions. All the needed
> information _is_ there, like the example you showed the other day, some
> of it could probably be
On Sun, Nov 30, 2008 at 04:06:00PM -0600, DJ Lucas wrote:
>
> Well..you'll probably be treading water for a bit. BLFS is nowhere near
> ready for LFS-6.4, though we are getting there.
Bummer. I guess I mis-read a post which led me to believe that BLFS
had advanced to the point of not being ba
Stealth wrote:
> I am following the book as it is written. The only exception was I
> used kernel 2.6.27.7 .
>
This is not good, though not likely the cause of the problem you are
seeing. You should be using 2.6.22.19. The latest 2.6.22.x should be
safe as far as kernel headers and udev are
Scott wrote:
> Wow, I can't believe I've made it this far without disaster!
>
> Just a question here: The book (6.4-rc1) warns to ensure that none of
> the programs to be stripped are running, and suggests re-chrooting "if
> unsure whether chroot was properly entered". However, I recall that in
>
For what its worth, this newbie did LFS at least four times before I
got it right.
On Nov 30, 2008, at 11:21 AM, Scott wrote:
> Wow, I can't believe I've made it this far without disaster!
>
> Just a question here: The book (6.4-rc1) warns to ensure that none of
> the programs to be stripped a
On Sunday 30 November 2008 04:21:44 pm Jeremy Huntwork wrote:
> Stealth wrote:
> > On Sunday 30 November 2008 03:33:05 pm Wolfgang Messingschlager
> >
> > wrote:
> >> Stealth wrote:
> >>> On Sunday 30 November 2008 02:17:30 pm Herman Gerritsen wrote:
> > gcc -dumpspecs | sed '[EMAIL PROTECTED]/
Stealth wrote:
> On Sunday 30 November 2008 03:33:05 pm Wolfgang Messingschlager
> wrote:
>> Stealth wrote:
>>> On Sunday 30 November 2008 02:17:30 pm Herman Gerritsen wrote:
> gcc -dumpspecs | sed '[EMAIL PROTECTED]/lib/ld-linux.so.2@/tools&@g' \
>
> > `dirname $(gcc -print-libgcc-fi
On Sunday 30 November 2008 03:33:05 pm Wolfgang Messingschlager
wrote:
> Stealth wrote:
> > On Sunday 30 November 2008 02:17:30 pm Herman Gerritsen wrote:
> >>> gcc -dumpspecs | sed '[EMAIL PROTECTED]/lib/ld-linux.so.2@/tools&@g' \
> >>>
> >>> > `dirname $(gcc -print-libgcc-file-name)`/specs
> >>
Stealth wrote:
> On Sunday 30 November 2008 02:17:30 pm Herman Gerritsen wrote:
>>> gcc -dumpspecs | sed '[EMAIL PROTECTED]/lib/ld-linux.so.2@/tools&@g' \
>>>
>>> > `dirname $(gcc -print-libgcc-file-name)`/specs
>>>
>>> and I get:
>>>
>>> sed: can't read /usr/lib/gcc/i486-pc-linux-gnu/4.1.2/specs:
On Sunday 30 November 2008 02:17:30 pm Herman Gerritsen wrote:
> > gcc -dumpspecs | sed '[EMAIL PROTECTED]/lib/ld-linux.so.2@/tools&@g' \
> >
> > > `dirname $(gcc -print-libgcc-file-name)`/specs
> >
> > and I get:
> >
> > sed: can't read /usr/lib/gcc/i486-pc-linux-gnu/4.1.2/specs: No
> > such file
> gcc -dumpspecs | sed '[EMAIL PROTECTED]/lib/ld-linux.so.2@/tools&@g' \
> > `dirname $(gcc -print-libgcc-file-name)`/specs
>
> and I get:
>
> sed: can't read /usr/lib/gcc/i486-pc-linux-gnu/4.1.2/specs: No such
> file or directory
Did you check your $PATH variable?
I believe the directory that is
When I finished the build of glibc I was still
in /mnt/lfs/sources/glibc-build.
I ran:
mv -v /tools/bin/{ld,ld-old}
mv -v /tools/$(gcc -dumpmachine)/bin/{ld,ld-old}
mv -v /tools/bin/{ld-new,ld}
ln -sv /tools/bin/ld /tools/$(gcc -dumpmachine)/bin/ld
then I ran:
gcc -dumpspecs | sed '[EMAIL PROT
Wow, I can't believe I've made it this far without disaster!
Just a question here: The book (6.4-rc1) warns to ensure that none of
the programs to be stripped are running, and suggests re-chrooting "if
unsure whether chroot was properly entered". However, I recall that in
the bash chapter we were
Hi there,
I overlooked a mistake on my side.
(Somehow these things come to mind after writing a post...)
The LFS users .bashrc contained a wrong $PATH variable
I somehow ommited the /tools/bin...
Thanks anyway, and sorry...
Herman Gerritsen
On Sun, Nov 30, 2008 at 12:57 PM, Herman Gerritsen
Hi there,
I see something wierd in the follwing line from the lfs-6.3 book (it
is in chapter 5.7):
Though I did not check it seems to be the same in the new lfs-6.4 book.
GCC_INCLUDEDIR=`dirname $(gcc -print-libgcc-file-name)`/include &&
find ${GCC_INCLUDEDIR}/* -maxdepth 0 -xtype d -exec rm -rvf
I tried to rebuild bison after /tools directory was removed and there
are still reference to it in bison executable. But there's a reference
to glibc build directory too. However, bison is working so I think your
build is broken for another reason.
You should try to rebuild it and run test suite t
On Fri, 2008-11-28 at 23:59 +0100, Renaud Marquet wrote:
> As gcc, glibc and binutils are all built with /tools/bin/gcc it's
> obvious they contain debug information referencing /tools/...
>
> Don't know why bison is, though. Maybe it's because gcc contains this
> reference too. I just checked my
23 matches
Mail list logo
