Re: [lfs-support] Installing Binutils and GCC after adjusting toolchain

[Ken Moffat]

On Thu, Nov 15, 2012 at 03:09:13PM +0100, Kaleb van Ingen Schenau wrote:
> Still no luck, i've made a 100% sure i start with a fresh copy of the
> extracted gcc.4.7.1.tar.bzp2 and i use a fresh gcc-build directory.
> 
> I can give you a summary of my actions if that helps.
> 1. untar binutils, run the test, apply patch
> 2. make a binutils-build directory
> 3. prepare the compile (copy pasting the config prefixes)
> 4. Compile and copy the command that has to be run afterwards from the book
> 5. install GMP, MPFR and MPC
> 6. untar GCC to gcc.4.7.1, switch to the gcc-4.7.1 folder, run the commands
> and make the gcc-build folder inside my gcc-4.7.1 folder.
> 7. Prepare for compille by copy pasting all the commands.
> 8. Make , ulimit -s 32768, make -k check, check the summary (all good and
> matching the log results from the LFS website)
> 9.Make install
> 10. create the links by using the "ln" commands while still in the
> gcc-build dir.
> 11. run the test, while still in the gcc-build dir.
> 12. get messed up results
> 13. cry myself to sleep holding a little tux.
> 
> I'm praying one of u guys/girls will now tell me that i made a simple
> mistake and can provide a easy fix because i'm starting to run out of
> back-up plans.
> 
> regards,
> Kaleb
> 
 Hi, Kaleb.

 As I said before, I'm out of ideas.  As I also said, please don't
top post - we don't like it on the LFS lists.

 Anyway, now that I've got a little time to spare, I've dug around.
 Google found some links to past threads (gcc-4.4, 4.5!) which seem
similar. Unfortunately, the links were to gmane, only containing the
day and month, so I can't point to the versions in the LFS archives,
and anyway the resolutions were a bit sketchy.

 What I can tell you is that one of the people reported that
reinstalling binutils fixed the problem.  Unfortunately, I've no
idea what went wrong in his first attempt, so I can't point to
anything that you should watch for.

 Perhaps using 'ldd' on /usr/bin/ld might show a problem ?
Looking at the binutils instructions in 6.13, nothing looks
particularly likely to cause problems :

1. the 'spawn ls' test will show that you will be able to run the
testsuite, it doesn't affect the install.

2. removing standards.info doesn't affect how the programs work.

3. the patch fixes a compiler failure if you use -O3 in your CFLAGS.

4. The first time, I hope your binutils-build directory was new,
ditto the untarred source (i.e. neither should be left over from
chapter 5).  In theory, the source should not be updated during the
build process, but safety-first - and you seem to have done that on
the rerun.

5. I suppose it is possible to miss that "tooldir=/usr" needs to be
specified for _both_ 'make' and 'make install'.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] Installing Binutils and GCC after adjusting toolchain

[Kaleb van Ingen Schenau]

Still no luck, i've made a 100% sure i start with a fresh copy of the
extracted gcc.4.7.1.tar.bzp2 and i use a fresh gcc-build directory.

I can give you a summary of my actions if that helps.
1. untar binutils, run the test, apply patch
2. make a binutils-build directory
3. prepare the compile (copy pasting the config prefixes)
4. Compile and copy the command that has to be run afterwards from the book
5. install GMP, MPFR and MPC
6. untar GCC to gcc.4.7.1, switch to the gcc-4.7.1 folder, run the commands
and make the gcc-build folder inside my gcc-4.7.1 folder.
7. Prepare for compille by copy pasting all the commands.
8. Make , ulimit -s 32768, make -k check, check the summary (all good and
matching the log results from the LFS website)
9.Make install
10. create the links by using the "ln" commands while still in the
gcc-build dir.
11. run the test, while still in the gcc-build dir.
12. get messed up results
13. cry myself to sleep holding a little tux.

I'm praying one of u guys/girls will now tell me that i made a simple
mistake and can provide a easy fix because i'm starting to run out of
back-up plans.

regards,
Kaleb

On Thu, Nov 15, 2012 at 9:52 AM, Kaleb van Ingen Schenau <
k.ingen.sche...@gmail.com> wrote:

> make install was run and no errors what so ever, what i'll do is go back
> to my snapshot i made after 6.10, i tried this before but im gonna go ahead
> and do it again just to see if i dont have my old gcc-build folder hanging
> around.
> Ill let you know if i encounter the same problem again after the 3rd
> attempt of getting past this.
>
> You will hear from me soon,
> Kaleb
>
> On Thu, Nov 15, 2012 at 1:49 AM, Ken Moffat wrote:
>
>> On Thu, Nov 15, 2012 at 12:42:03AM +0100, Kaleb van Ingen Schenau wrote:
>> > Hi, and thanks for the respond
>> >
>> > Throughout the book i've encountered 0 problems or errors and everything
>> > goes according to the book. It just seems weird that everything works as
>> > intended at chapter 6.10 then somewhere between that and compiling
>> > bin-utils and GCC it messes up somewhere, could this be something that i
>> > maybe mistyped earlier and i'm not experiencing the effects from. (Note
>> > that EVERY test till this point have been 100% accurate to what to book
>> > states it should be)
>> > But to anwser your questions:
>> > >>Then when i run:
>> > > >#grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g'
>> > >> SEARCH_DIR("/tools/i686-pc-linux-gnu/lib")
>> > >> SEARCH_DIR("/usr/lib")
>> > >> SEARCH_DIR("/lib");
>> > >>
>> > >> which is also not correct
>> >
>> > >That seems to be correct - please compare it to the book - 3
>> > >matches, for /tools/i686-pc-linux-gnu, /usr/lib, /lib.  For this
>> > >part I don't see any error - please point it out if I'm wrong!
>> >
>> > The book says it should be:
>> > SEARCH_DIR("/usr/i686-pc-linux-gnu/lib")
>> > SEARCH_DIR("/usr/local/lib")
>> > SEARCH_DIR("/lib")
>> > SEARCH_DIR("/usr/lib");
>> >
>> > So I'm somehow still pointing to /tools while it seems that i should be
>> > searching in /usr and /lib, i think this might a main reason why it
>> isn't
>> > working.
>> >
>>  You were right all along, it doesn't match : I'll have to blame the
>> prescription painkillers I'm on (only ibuprofen and paracetomol!).
>> Sorry, no idea how I misread what the book says.
>>
>> > >Are you doing something unusual ?  That probably includes building
>> > >on a virtual machine, using the package_users hint, and building on
>> > >mingw or whatever on windows.  Or using minimalist packages (dash,
>> > >busybox).  If this is a straight build linux from linux, did you
>> > >check the host against the Host System Requirements in the preface ?
>> >
>> > I'm building on a virtual PC running Centos 6.3 which i think fit the
>> Host
>> > System Requirements, other then that I'm not using anything the book
>> > doesn't tell me to and i haven't skipped anything, I'm just doing what
>> the
>> > book is telling me to do. Have the logs been of any help maybe?
>> > pastebin.com/dCjzz5yb << or is there anything else i can supply you
>> > with to help me?
>> >
>> [ snipping my original reply below this - please don't top post, and
>> trim what you are replying to. ]
>>
>>  I've no idea about virtual machines, maybe someone else can offer
>> suggestions about specific changes (if any) needed - but I don't
>> recall seeing problems from them apart from selecting the right
>> kernel options.
>>
>>  So to recap, hopefully correctly - your include directories from
>> gcc are not as expected, and the SEARCH_DIRs begin in /tools.
>>
>>  That last point is correct for 6.10 (hmm, maybe I was looking there
>> instead of 6.17 when I replied).
>>
>>  Going back to check my _own_ (64-bit) logs from 7.2 (with a lot of
>> things collected up), in 6.10 I see that I have:
>> ignoring nonexistent directory
>>
>> "/tools/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../x86_64-unknown-linux-gnu/include"
>> ignoring duplicate directory "/tools/include"
>> #includ

Re: [lfs-support] Installing Binutils and GCC after adjusting toolchain

[Kaleb van Ingen Schenau]

make install was run and no errors what so ever, what i'll do is go back to
my snapshot i made after 6.10, i tried this before but im gonna go ahead
and do it again just to see if i dont have my old gcc-build folder hanging
around.
Ill let you know if i encounter the same problem again after the 3rd
attempt of getting past this.

You will hear from me soon,
Kaleb

On Thu, Nov 15, 2012 at 1:49 AM, Ken Moffat  wrote:

> On Thu, Nov 15, 2012 at 12:42:03AM +0100, Kaleb van Ingen Schenau wrote:
> > Hi, and thanks for the respond
> >
> > Throughout the book i've encountered 0 problems or errors and everything
> > goes according to the book. It just seems weird that everything works as
> > intended at chapter 6.10 then somewhere between that and compiling
> > bin-utils and GCC it messes up somewhere, could this be something that i
> > maybe mistyped earlier and i'm not experiencing the effects from. (Note
> > that EVERY test till this point have been 100% accurate to what to book
> > states it should be)
> > But to anwser your questions:
> > >>Then when i run:
> > > >#grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g'
> > >> SEARCH_DIR("/tools/i686-pc-linux-gnu/lib")
> > >> SEARCH_DIR("/usr/lib")
> > >> SEARCH_DIR("/lib");
> > >>
> > >> which is also not correct
> >
> > >That seems to be correct - please compare it to the book - 3
> > >matches, for /tools/i686-pc-linux-gnu, /usr/lib, /lib.  For this
> > >part I don't see any error - please point it out if I'm wrong!
> >
> > The book says it should be:
> > SEARCH_DIR("/usr/i686-pc-linux-gnu/lib")
> > SEARCH_DIR("/usr/local/lib")
> > SEARCH_DIR("/lib")
> > SEARCH_DIR("/usr/lib");
> >
> > So I'm somehow still pointing to /tools while it seems that i should be
> > searching in /usr and /lib, i think this might a main reason why it isn't
> > working.
> >
>  You were right all along, it doesn't match : I'll have to blame the
> prescription painkillers I'm on (only ibuprofen and paracetomol!).
> Sorry, no idea how I misread what the book says.
>
> > >Are you doing something unusual ?  That probably includes building
> > >on a virtual machine, using the package_users hint, and building on
> > >mingw or whatever on windows.  Or using minimalist packages (dash,
> > >busybox).  If this is a straight build linux from linux, did you
> > >check the host against the Host System Requirements in the preface ?
> >
> > I'm building on a virtual PC running Centos 6.3 which i think fit the
> Host
> > System Requirements, other then that I'm not using anything the book
> > doesn't tell me to and i haven't skipped anything, I'm just doing what
> the
> > book is telling me to do. Have the logs been of any help maybe?
> > pastebin.com/dCjzz5yb << or is there anything else i can supply you
> > with to help me?
> >
> [ snipping my original reply below this - please don't top post, and
> trim what you are replying to. ]
>
>  I've no idea about virtual machines, maybe someone else can offer
> suggestions about specific changes (if any) needed - but I don't
> recall seeing problems from them apart from selecting the right
> kernel options.
>
>  So to recap, hopefully correctly - your include directories from
> gcc are not as expected, and the SEARCH_DIRs begin in /tools.
>
>  That last point is correct for 6.10 (hmm, maybe I was looking there
> instead of 6.17 when I replied).
>
>  Going back to check my _own_ (64-bit) logs from 7.2 (with a lot of
> things collected up), in 6.10 I see that I have:
> ignoring nonexistent directory
>
> "/tools/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../x86_64-unknown-linux-gnu/include"
> ignoring duplicate directory "/tools/include"
> #include "..." search starts here:
> #include <...> search starts here:
>  /usr/include
>  /tools/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/include
>  /tools/include
>  /tools/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/include-fixed
>
> and
> SEARCH_DIR("/tools/x86_64-unknown-linux-gnu/lib64");
> SEARCH_DIR("/tools/x86_64-unknown-linux-gnu/lib");
> SEARCH_DIR("/usr/lib"); SEARCH_DIR("/lib");
> (this time, word-wrapping has mad a long line become 3 individual
> lines).
>
>  I *think* that looks as if your results at the end of 6.17 match,
> or are at least similar to, your results in 6.10 ?  Is it possible
> that you omitted 'make install' after running the tests on gcc ?
>
>  Other than that, I'm again out of ideas.
>
> ĸen
> --
> das eine Mal als Tragödie, das andere Mal als Farce
> --
> http://linuxfromscratch.org/mailman/listinfo/lfs-support
> FAQ: http://www.linuxfromscratch.org/lfs/faq.html
> Unsubscribe: See the above information page
>
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] Installing Binutils and GCC after adjusting toolchain

[Ken Moffat]

On Wed, Nov 14, 2012 at 07:08:26PM -0600, Bruce Dubbs wrote:
> Ken Moffat wrote:
> 
> >   I've no idea about virtual machines, maybe someone else can offer
> > suggestions about specific changes (if any) needed - but I don't
> > recall seeing problems from them apart from selecting the right
> > kernel options.
> 
> 
> If the appropriate virtual file systems are mounted (/sys, /dev, /proc, 
> etc) there are no changes needed to build LFS.  From a theoretical 
> standpoint where would the changes be?  The only code that accesses hw 
> is in the kernel drivers.
> 

Bruce,

 I try not to theorise these days - except when looking at problems.
I _do_ recall reading some posts, perhaps on blfs-support, where
people had problems in virtual machines.  I did say "(if any)" - I'm
happy to take your assurance that none are needed, but no closer to
understanding what has caused the OP's problem (and still not
interested in using a virtual machine).

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] Installing Binutils and GCC after adjusting toolchain

[Bruce Dubbs]

Ken Moffat wrote:

>   I've no idea about virtual machines, maybe someone else can offer
> suggestions about specific changes (if any) needed - but I don't
> recall seeing problems from them apart from selecting the right
> kernel options.

Ken,
   I've built LFS several times in different virtual environments.  For 
instance, BLFS shows how to build qemu-kvm.  When I was developing that, 
I loaded a Fedora iso and built LFS from there.  There were no 
differences that I recall except that the kernel drivers have to be 
specified for the virtual hardware.  The host, of course, was LFS.

If the appropriate virtual file systems are mounted (/sys, /dev, /proc, 
etc) there are no changes needed to build LFS.  From a theoretical 
standpoint where would the changes be?  The only code that accesses hw 
is in the kernel drivers.

LFS -> qemu-kvm -> Fedora -> /mnt/lfs -> new lfs

Substitute the first host, virtual system, and virtual host with your 
choice.  Any should work.

The same goes for

any host -> ssh linux target -> /mnt/lfs -> new lfs


   -- Bruce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] Installing Binutils and GCC after adjusting toolchain

[Ken Moffat]

On Thu, Nov 15, 2012 at 12:42:03AM +0100, Kaleb van Ingen Schenau wrote:
> Hi, and thanks for the respond
> 
> Throughout the book i've encountered 0 problems or errors and everything
> goes according to the book. It just seems weird that everything works as
> intended at chapter 6.10 then somewhere between that and compiling
> bin-utils and GCC it messes up somewhere, could this be something that i
> maybe mistyped earlier and i'm not experiencing the effects from. (Note
> that EVERY test till this point have been 100% accurate to what to book
> states it should be)
> But to anwser your questions:
> >>Then when i run:
> > >#grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g'
> >> SEARCH_DIR("/tools/i686-pc-linux-gnu/lib")
> >> SEARCH_DIR("/usr/lib")
> >> SEARCH_DIR("/lib");
> >>
> >> which is also not correct
> 
> >That seems to be correct - please compare it to the book - 3
> >matches, for /tools/i686-pc-linux-gnu, /usr/lib, /lib.  For this
> >part I don't see any error - please point it out if I'm wrong!
> 
> The book says it should be:
> SEARCH_DIR("/usr/i686-pc-linux-gnu/lib")
> SEARCH_DIR("/usr/local/lib")
> SEARCH_DIR("/lib")
> SEARCH_DIR("/usr/lib");
> 
> So I'm somehow still pointing to /tools while it seems that i should be
> searching in /usr and /lib, i think this might a main reason why it isn't
> working.
> 
 You were right all along, it doesn't match : I'll have to blame the
prescription painkillers I'm on (only ibuprofen and paracetomol!).
Sorry, no idea how I misread what the book says.

> >Are you doing something unusual ?  That probably includes building
> >on a virtual machine, using the package_users hint, and building on
> >mingw or whatever on windows.  Or using minimalist packages (dash,
> >busybox).  If this is a straight build linux from linux, did you
> >check the host against the Host System Requirements in the preface ?
> 
> I'm building on a virtual PC running Centos 6.3 which i think fit the Host
> System Requirements, other then that I'm not using anything the book
> doesn't tell me to and i haven't skipped anything, I'm just doing what the
> book is telling me to do. Have the logs been of any help maybe?
> pastebin.com/dCjzz5yb << or is there anything else i can supply you
> with to help me?
> 
[ snipping my original reply below this - please don't top post, and
trim what you are replying to. ]

 I've no idea about virtual machines, maybe someone else can offer
suggestions about specific changes (if any) needed - but I don't
recall seeing problems from them apart from selecting the right
kernel options.

 So to recap, hopefully correctly - your include directories from
gcc are not as expected, and the SEARCH_DIRs begin in /tools.

 That last point is correct for 6.10 (hmm, maybe I was looking there
instead of 6.17 when I replied).

 Going back to check my _own_ (64-bit) logs from 7.2 (with a lot of
things collected up), in 6.10 I see that I have:
ignoring nonexistent directory
"/tools/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../x86_64-unknown-linux-gnu/include"
ignoring duplicate directory "/tools/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include
 /tools/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/include
 /tools/include
 /tools/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/include-fixed

and
SEARCH_DIR("/tools/x86_64-unknown-linux-gnu/lib64");
SEARCH_DIR("/tools/x86_64-unknown-linux-gnu/lib");
SEARCH_DIR("/usr/lib"); SEARCH_DIR("/lib");
(this time, word-wrapping has mad a long line become 3 individual
lines).

 I *think* that looks as if your results at the end of 6.17 match,
or are at least similar to, your results in 6.10 ?  Is it possible
that you omitted 'make install' after running the tests on gcc ?

 Other than that, I'm again out of ideas.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] Installing Binutils and GCC after adjusting toolchain

[Kaleb van Ingen Schenau]

Hi, and thanks for the respond

Throughout the book i've encountered 0 problems or errors and everything
goes according to the book. It just seems weird that everything works as
intended at chapter 6.10 then somewhere between that and compiling
bin-utils and GCC it messes up somewhere, could this be something that i
maybe mistyped earlier and i'm not experiencing the effects from. (Note
that EVERY test till this point have been 100% accurate to what to book
states it should be)
But to anwser your questions:
>>Then when i run:
> >#grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g'
>> SEARCH_DIR("/tools/i686-pc-linux-gnu/lib")
>> SEARCH_DIR("/usr/lib")
>> SEARCH_DIR("/lib");
>>
>> which is also not correct

>That seems to be correct - please compare it to the book - 3
>matches, for /tools/i686-pc-linux-gnu, /usr/lib, /lib.  For this
>part I don't see any error - please point it out if I'm wrong!

The book says it should be:
SEARCH_DIR("/usr/i686-pc-linux-gnu/lib")
SEARCH_DIR("/usr/local/lib")
SEARCH_DIR("/lib")
SEARCH_DIR("/usr/lib");

So I'm somehow still pointing to /tools while it seems that i should be
searching in /usr and /lib, i think this might a main reason why it isn't
working.

>Are you doing something unusual ?  That probably includes building
>on a virtual machine, using the package_users hint, and building on
>mingw or whatever on windows.  Or using minimalist packages (dash,
>busybox).  If this is a straight build linux from linux, did you
>check the host against the Host System Requirements in the preface ?

I'm building on a virtual PC running Centos 6.3 which i think fit the Host
System Requirements, other then that I'm not using anything the book
doesn't tell me to and i haven't skipped anything, I'm just doing what the
book is telling me to do. Have the logs been of any help maybe?
pastebin.com/dCjzz5yb << or is there anything else i can supply you
with to help me?


On Wed, Nov 14, 2012 at 7:50 PM, Ken Moffat  wrote:

> On Wed, Nov 14, 2012 at 09:01:42AM +0100, Kaleb van Ingen Schenau wrote:
> > Hello,
> >
> > I'm having a bit of a problem which is stopping me from continueing with
> > LFS, after chapter 6.10 "Adjusting the Toolchain" i run the sanity check
> > and all results come out as they are supposed to be according to the
> book.
> >
>
>  Hi, thanks for the prompt after the thread got hijacked :)  I'm not
> at my best at the moment, and I haven't built for 32-bit in a very
> long time.  But I'm now at my desktop instead of ssh'ing to the
> server from a tty on the netbook, so let's see if I can offer
> anything -
>
> > But after i install Binutils MPFR, MPC, GMP, ZLIB, FILE and Gcc (not in
> > that order)
>  I will assume you followed the book's order :)
> > the results of the test discribed in the install/compile
> > section of GCC dont come out as they are supposed to be when i run:
> > #echo 'main(){}' > dummy.c
> > #cc dummy.c -v -Wl,--verbose &> dummy.log
> > #readelf -l a.out | grep ': /lib'
> >
> > i get : [Requesting program interpreter: /lib/ld-linux.so.2] which is
> > intented
> > when i then run :
> > #grep -o '/usr/lib.*/crt[1in].*succeeded' dummy.log
> > it gives me:
> > /usr/lib/crt1.o succeeded
> > /usr/lib/crti.o succeeded
> > /usr/lib/crtn.o succeeded
> >
> > instead of the intended:
> > /usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../crt1.o succeeded
> > /usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../crti.o succeeded
> > /usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../crtn.o succeeded
> >
>  Not wrong, just different :)  If you work out where these files are
> (i.e. step up a directory for every '../') you will see that they
> actually are in /usr/lib in both your result and what the book
> expects.
>
>  In my own 64-bit logs they have ... 4.7.1/../../../lib64/crt1.o
> which implies that the book's version is expected on 32-bit.
> > Then when i run :
> > #grep -B4 '^ /usr/include' dummy.log
> >
> > it states:
> > Ignoring nonexistent directory
> >
> "/tools/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../../i686-pc-linux-gnu/include
> > Ignoring duplicate directory "/tools/include"
> > #include "..." search starts here:
> > #include <...> search starts here:
> > /usr/include
> >
>
>  On 64-bit I get an 'Ignoring nonexistent directory' message,
> followed by /usr/lib/gcc/.../include /usr/local/include
> /usr/lib/gcc/.../include-fixed and /usr/include-fixed.
>
>  So, you are not referencing the gcc /include and include-fixed
> directories, nor /usr/local/include.
>
> > Then when i run:
> > #grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g'
> > SEARCH_DIR("/tools/i686-pc-linux-gnu/lib")
> > SEARCH_DIR("/usr/lib")
> > SEARCH_DIR("/lib");
> >
> > which is also not correct
>
>  That seems to be correct - please compare it to the book - 3
> matches, for /tools/i686-pc-linux-gnu, /usr/lib, /lib.  For this
> part I don't see any error - please point it out if I'm wrong!
> >
> > #grep "/lib.*/libc.so.6 " dummy.log
> > and
> > #grep found dummy.log
> > DO come up with the correct 

Re: [lfs-support] Installing Binutils and GCC after adjusting toolchain

[Ken Moffat]

On Wed, Nov 14, 2012 at 09:01:42AM +0100, Kaleb van Ingen Schenau wrote:
> Hello,
> 
> I'm having a bit of a problem which is stopping me from continueing with
> LFS, after chapter 6.10 "Adjusting the Toolchain" i run the sanity check
> and all results come out as they are supposed to be according to the book.
> 

 Hi, thanks for the prompt after the thread got hijacked :)  I'm not
at my best at the moment, and I haven't built for 32-bit in a very
long time.  But I'm now at my desktop instead of ssh'ing to the
server from a tty on the netbook, so let's see if I can offer
anything -

> But after i install Binutils MPFR, MPC, GMP, ZLIB, FILE and Gcc (not in
> that order)
 I will assume you followed the book's order :)
> the results of the test discribed in the install/compile
> section of GCC dont come out as they are supposed to be when i run:
> #echo 'main(){}' > dummy.c
> #cc dummy.c -v -Wl,--verbose &> dummy.log
> #readelf -l a.out | grep ': /lib'
> 
> i get : [Requesting program interpreter: /lib/ld-linux.so.2] which is
> intented
> when i then run :
> #grep -o '/usr/lib.*/crt[1in].*succeeded' dummy.log
> it gives me:
> /usr/lib/crt1.o succeeded
> /usr/lib/crti.o succeeded
> /usr/lib/crtn.o succeeded
> 
> instead of the intended:
> /usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../crt1.o succeeded
> /usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../crti.o succeeded
> /usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../crtn.o succeeded
> 
 Not wrong, just different :)  If you work out where these files are
(i.e. step up a directory for every '../') you will see that they
actually are in /usr/lib in both your result and what the book
expects.

 In my own 64-bit logs they have ... 4.7.1/../../../lib64/crt1.o
which implies that the book's version is expected on 32-bit.
> Then when i run :
> #grep -B4 '^ /usr/include' dummy.log
> 
> it states:
> Ignoring nonexistent directory
> "/tools/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../../i686-pc-linux-gnu/include
> Ignoring duplicate directory "/tools/include"
> #include "..." search starts here:
> #include <...> search starts here:
> /usr/include
> 

 On 64-bit I get an 'Ignoring nonexistent directory' message,
followed by /usr/lib/gcc/.../include /usr/local/include
/usr/lib/gcc/.../include-fixed and /usr/include-fixed.

 So, you are not referencing the gcc /include and include-fixed
directories, nor /usr/local/include.

> Then when i run:
> #grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g'
> SEARCH_DIR("/tools/i686-pc-linux-gnu/lib")
> SEARCH_DIR("/usr/lib")
> SEARCH_DIR("/lib");
> 
> which is also not correct

 That seems to be correct - please compare it to the book - 3
matches, for /tools/i686-pc-linux-gnu, /usr/lib, /lib.  For this
part I don't see any error - please point it out if I'm wrong!
> 
> #grep "/lib.*/libc.so.6 " dummy.log
> and
> #grep found dummy.log
> DO come up with the correct output
> 
> This is the link to dummy.log:
> pastebin.com/dCjzz5yb
> 
> Hope this helps and someone can shed some light on what part im messing up
> on between 6.10 and 6.17

 So, at the end of 6.10 everything was good, but now the include
path is wrong (doubled /tools/include, and only /usr/include) ?

 Are you doing something unusual ?  That probably includes building
on a virtual machine, using the package_users hint, and building on
mingw or whatever on windows.  Or using minimalist packages (dash,
busybox).  If this is a straight build linux from linux, did you
check the host against the Host System Requirements in the preface ?

 Sorry, I'm struggling to understand what has caused this
difference.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] Installing Binutils and GCC after adjusting toolchain

[Kaleb van Ingen Schenau]

Hey guys,

Note that we've switched topic in thread, hate to be rude like this but i'm
just making sure that the original help-request is still open and waiting
for a guardian angel to share his/her mighty wisdom and help me work out
why I'm stuck,

Kind regards,
Kaleb.

Link to topic :
http://linuxfromscratch.org/pipermail/lfs-support/2012-November/043946.html
On Wed, Nov 14, 2012 at 4:37 PM, William Harrington wrote:

>
> On Nov 14, 2012, at 2:31 AM, Paige Thompson wrote:
>
> what do I do when I get to this part and it just keeps telling me no such
> file or directory no such file or directory no such file or directory:
>
> chroot "$LFS" /tools/bin/env -i \
> HOME=/root TERM="$TERM" PS1='\u:\w\$ ' \
> PATH=/bin:/usr/bin:/sbin:/usr/sbin:/tools/bin \
> /tools/bin/bash --login +h
>
>
>
> http://www.linuxfromscratch.org/lfs/faq.html#any-no-such-file
>
> Make sure it isn't linked to host libs ( /lib instead of /tools/lib )
>
> Sincerely,
>
> William Harrington
>
> --
> http://linuxfromscratch.org/mailman/listinfo/lfs-support
> FAQ: http://www.linuxfromscratch.org/lfs/faq.html
> Unsubscribe: See the above information page
>
>
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] Installing Binutils and GCC after adjusting toolchain

[William Harrington]

On Nov 14, 2012, at 2:31 AM, Paige Thompson wrote:

what do I do when I get to this part and it just keeps telling me no  
such file or directory no such file or directory no such file or  
directory:

chroot "$LFS" /tools/bin/env -i \
HOME=/root TERM="$TERM" PS1='\u:\w\$ ' \
PATH=/bin:/usr/bin:/sbin:/usr/sbin:/tools/bin \
/tools/bin/bash --login +h



http://www.linuxfromscratch.org/lfs/faq.html#any-no-such-file

Make sure it isn't linked to host libs ( /lib instead of /tools/lib )

Sincerely,

William Harrington-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] Installing Binutils and GCC after adjusting toolchain

[Paige Thompson]

what do I do when I get to this part and it just keeps telling me no such file 
or directory no such file or directory no such file or directory: 
chroot "$LFS" /tools/bin/env -i \
HOME=/root TERM="$TERM" PS1='\u:\w\$ ' \
PATH=/bin:/usr/bin:/sbin:/usr/sbin:/tools/bin \
/tools/bin/bash --login +h

On Nov 14, 2012, at 12:22 AM, Paige Thompson  wrote:

> I found a quick fix for my problem, 
> 
> dev@dev-VirtualBox /mnt/erraticOS/tools/x86_64-linux-gnu/bin $ ls
> a.out  ar  as  gcc  ld  ld.bfd  nm  objcopy  objdump  ranlib  strip
> 
> I moved ld and as to .old and created symlinks to the host's ld and as and 
> the make -C ld LIB_PATH=/usr/lib:/lib finished and produced the ld-new file: 
> 
> dev@dev-VirtualBox /mnt/erraticOS/tools/bin $ ldd ld-new 
> linux-vdso.so.1 =>  (0x7fffd1fdc000)
> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f24b10c6000)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f24b0d09000)
> /tools/lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 
> (0x7f24b12e)
> dev@dev-VirtualBox /mnt/erraticOS/tools/bin $ ldd ld
> linux-vdso.so.1 =>  (0x7fff3ad7)
> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fde0e3ce000)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fde0e011000)
> /tools/lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 
> (0x7fde0e5e8000)
> dev@dev-VirtualBox /mnt/erraticOS/tools/bin $ 
> 
> doesn't really look right, nfc what to do about it. *shrug*
> 
> 
> 
> On Nov 14, 2012, at 12:07 AM, Paige Thompson  wrote:
> 
>> hahahahah, thats funny, right as this email arrived I was trying to figure 
>> out the following (pass 2 of binutils): 
>> 
>> dev@dev-VirtualBox /mnt/erraticOS/usr/src/binutils-build $ make -C ld 
>> LIB_PATH=/usr/lib:/lib
>> make: Entering directory `/src/binutils-build/ld'make  all-recursivemake[1]: 
>> Entering directory `/src/binutils-build/ld'Making all in po
>> make[2]: Entering directory `/src/binutils-build/ld/po'
>> make[2]: Nothing to be done for `all'.
>> make[2]: Leaving directory `/src/binutils-build/ld/po'
>> make[2]: Entering directory `/src/binutils-build/ld'
>> /bin/bash ./libtool  --tag=CC   --mode=compile 
>> /mnt/erraticOS/tools/bin/x86_64-linux-gnu-gcc -DHAVE_CONFIG_H -I. 
>> -I../../binutils/ld  -I. -I../../binutils/ld -I../bfd 
>> -I../../binutils/ld/../bfd -I../../binutils/ld/../include  -g -O2 
>> -DENABLE_PLUGINS -DLOCALEDIR="\"/tools/share/locale\""  -g -O2 -g -O2 -MT 
>> libldtestplug_la-testplug.lo -MD -MP -MF .deps/libldtestplug_la-testplug.Tpo 
>> -c -o libldtestplug_la-testplug.lo `test -f 'testplug.c' || echo 
>> '../../binutils/ld/'`testplug.c
>> libtool: compile:  /mnt/erraticOS/tools/bin/x86_64-linux-gnu-gcc 
>> -DHAVE_CONFIG_H -I. -I../../binutils/ld -I. -I../../binutils/ld -I../bfd 
>> -I../../binutils/ld/../bfd -I../../binutils/ld/../include -g -O2 
>> -DENABLE_PLUGINS -DLOCALEDIR=\"/tools/share/locale\" -g -O2 -g -O2 -MT 
>> libldtestplug_la-testplug.lo -MD -MP -MF .deps/libldtestplug_la-testplug.Tpo 
>> -c ../../binutils/ld/testplug.c  -fPIC -DPIC -o 
>> .libs/libldtestplug_la-testplug.o
>> x86_64-linux-gnu-gcc: internal compiler error: Segmentation fault (program 
>> as)
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> See  for instructions.
>> make[2]: *** [libldtestplug_la-testplug.lo] Error 1
>> make[2]: Leaving directory `/src/binutils-build/ld'
>> make[1]: *** [all-recursive] Error 1
>> make[1]: Leaving directory `/src/binutils-build/ld'
>> make: *** [all] Error 2
>> make: Leaving directory `/src/binutils-build/ld'
>> dev@dev-VirtualBox /mnt/erraticOS/usr/src/binutils-build $ 
>> 
>> last week I got so sick of trying to fix it that I substituted ld from my OS 
>> which allowed me to get past this somehow but then I decided probably not 
>> such a great idea and came back to this, still nfc how to fix it. 
>> 
>> 
>> 
>> On Nov 14, 2012, at 12:01 AM, Kaleb van Ingen Schenau 
>>  wrote:
>> 
>>> Hello,
>>> 
>>> I'm having a bit of a problem which is stopping me from continueing with 
>>> LFS, after chapter 6.10 "Adjusting the Toolchain" i run the sanity check 
>>> and all results come out as they are supposed to be according to the book.
>>> 
>>> But after i install Binutils MPFR, MPC, GMP, ZLIB, FILE and Gcc (not in 
>>> that order) the results of the test discribed in the install/compile 
>>> section of GCC dont come out as they are supposed to be when i run:
>>> #echo 'main(){}' > dummy.c
>>> #cc dummy.c -v -Wl,--verbose &> dummy.log
>>> #readelf -l a.out | grep ': /lib'
>>> 
>>> i get : [Requesting program interpreter: /lib/ld-linux.so.2] which is 
>>> intented
>>> when i then run :
>>> #grep -o '/usr/lib.*/crt[1in].*succeeded' dummy.log
>>> it gives me:
>>> /usr/lib/crt1.o succeeded
>>> /usr/lib/crti.o succeeded
>>> /usr/lib/crtn.o succeeded
>>>  
>>> instead of the intended:
>>> /usr/lib/gcc/i686-pc-linux-gnu/

Re: [lfs-support] Installing Binutils and GCC after adjusting toolchain

[Paige Thompson]

I found a quick fix for my problem, 

dev@dev-VirtualBox /mnt/erraticOS/tools/x86_64-linux-gnu/bin $ ls
a.out  ar  as  gcc  ld  ld.bfd  nm  objcopy  objdump  ranlib  strip

I moved ld and as to .old and created symlinks to the host's ld and as and the 
make -C ld LIB_PATH=/usr/lib:/lib finished and produced the ld-new file: 

dev@dev-VirtualBox /mnt/erraticOS/tools/bin $ ldd ld-new 
linux-vdso.so.1 =>  (0x7fffd1fdc000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f24b10c6000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f24b0d09000)
/tools/lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 
(0x7f24b12e)
dev@dev-VirtualBox /mnt/erraticOS/tools/bin $ ldd ld
linux-vdso.so.1 =>  (0x7fff3ad7)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fde0e3ce000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fde0e011000)
/tools/lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 
(0x7fde0e5e8000)
dev@dev-VirtualBox /mnt/erraticOS/tools/bin $ 

doesn't really look right, nfc what to do about it. *shrug*



On Nov 14, 2012, at 12:07 AM, Paige Thompson  wrote:

> hahahahah, thats funny, right as this email arrived I was trying to figure 
> out the following (pass 2 of binutils): 
> 
> dev@dev-VirtualBox /mnt/erraticOS/usr/src/binutils-build $ make -C ld 
> LIB_PATH=/usr/lib:/lib
> make: Entering directory `/src/binutils-build/ld'make  all-recursivemake[1]: 
> Entering directory `/src/binutils-build/ld'Making all in po
> make[2]: Entering directory `/src/binutils-build/ld/po'
> make[2]: Nothing to be done for `all'.
> make[2]: Leaving directory `/src/binutils-build/ld/po'
> make[2]: Entering directory `/src/binutils-build/ld'
> /bin/bash ./libtool  --tag=CC   --mode=compile 
> /mnt/erraticOS/tools/bin/x86_64-linux-gnu-gcc -DHAVE_CONFIG_H -I. 
> -I../../binutils/ld  -I. -I../../binutils/ld -I../bfd 
> -I../../binutils/ld/../bfd -I../../binutils/ld/../include  -g -O2 
> -DENABLE_PLUGINS -DLOCALEDIR="\"/tools/share/locale\""  -g -O2 -g -O2 -MT 
> libldtestplug_la-testplug.lo -MD -MP -MF .deps/libldtestplug_la-testplug.Tpo 
> -c -o libldtestplug_la-testplug.lo `test -f 'testplug.c' || echo 
> '../../binutils/ld/'`testplug.c
> libtool: compile:  /mnt/erraticOS/tools/bin/x86_64-linux-gnu-gcc 
> -DHAVE_CONFIG_H -I. -I../../binutils/ld -I. -I../../binutils/ld -I../bfd 
> -I../../binutils/ld/../bfd -I../../binutils/ld/../include -g -O2 
> -DENABLE_PLUGINS -DLOCALEDIR=\"/tools/share/locale\" -g -O2 -g -O2 -MT 
> libldtestplug_la-testplug.lo -MD -MP -MF .deps/libldtestplug_la-testplug.Tpo 
> -c ../../binutils/ld/testplug.c  -fPIC -DPIC -o 
> .libs/libldtestplug_la-testplug.o
> x86_64-linux-gnu-gcc: internal compiler error: Segmentation fault (program as)
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> make[2]: *** [libldtestplug_la-testplug.lo] Error 1
> make[2]: Leaving directory `/src/binutils-build/ld'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/src/binutils-build/ld'
> make: *** [all] Error 2
> make: Leaving directory `/src/binutils-build/ld'
> dev@dev-VirtualBox /mnt/erraticOS/usr/src/binutils-build $ 
> 
> last week I got so sick of trying to fix it that I substituted ld from my OS 
> which allowed me to get past this somehow but then I decided probably not 
> such a great idea and came back to this, still nfc how to fix it. 
> 
> 
> 
> On Nov 14, 2012, at 12:01 AM, Kaleb van Ingen Schenau 
>  wrote:
> 
>> Hello,
>> 
>> I'm having a bit of a problem which is stopping me from continueing with 
>> LFS, after chapter 6.10 "Adjusting the Toolchain" i run the sanity check and 
>> all results come out as they are supposed to be according to the book.
>> 
>> But after i install Binutils MPFR, MPC, GMP, ZLIB, FILE and Gcc (not in that 
>> order) the results of the test discribed in the install/compile section of 
>> GCC dont come out as they are supposed to be when i run:
>> #echo 'main(){}' > dummy.c
>> #cc dummy.c -v -Wl,--verbose &> dummy.log
>> #readelf -l a.out | grep ': /lib'
>> 
>> i get : [Requesting program interpreter: /lib/ld-linux.so.2] which is 
>> intented
>> when i then run :
>> #grep -o '/usr/lib.*/crt[1in].*succeeded' dummy.log
>> it gives me:
>> /usr/lib/crt1.o succeeded
>> /usr/lib/crti.o succeeded
>> /usr/lib/crtn.o succeeded
>>  
>> instead of the intended:
>> /usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../crt1.o succeeded
>> /usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../crti.o succeeded
>> /usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../crtn.o succeeded
>> 
>> Then when i run :
>> #grep -B4 '^ /usr/include' dummy.log
>> 
>> it states:
>> Ignoring nonexistent directory 
>> "/tools/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../../i686-pc-linux-gnu/include
>> Ignoring duplicate directory "/tools/include"
>> #include "..." search starts here:
>> #include <...> search starts here:
>> /usr

Re: [lfs-support] Installing Binutils and GCC after adjusting toolchain

[Paige Thompson]

hahahahah, thats funny, right as this email arrived I was trying to figure out 
the following (pass 2 of binutils): 

dev@dev-VirtualBox /mnt/erraticOS/usr/src/binutils-build $ make -C ld 
LIB_PATH=/usr/lib:/lib
make: Entering directory `/src/binutils-build/ld'make  all-recursivemake[1]: 
Entering directory `/src/binutils-build/ld'Making all in po
make[2]: Entering directory `/src/binutils-build/ld/po'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/src/binutils-build/ld/po'
make[2]: Entering directory `/src/binutils-build/ld'
/bin/bash ./libtool  --tag=CC   --mode=compile 
/mnt/erraticOS/tools/bin/x86_64-linux-gnu-gcc -DHAVE_CONFIG_H -I. 
-I../../binutils/ld  -I. -I../../binutils/ld -I../bfd 
-I../../binutils/ld/../bfd -I../../binutils/ld/../include  -g -O2 
-DENABLE_PLUGINS -DLOCALEDIR="\"/tools/share/locale\""  -g -O2 -g -O2 -MT 
libldtestplug_la-testplug.lo -MD -MP -MF .deps/libldtestplug_la-testplug.Tpo -c 
-o libldtestplug_la-testplug.lo `test -f 'testplug.c' || echo 
'../../binutils/ld/'`testplug.c
libtool: compile:  /mnt/erraticOS/tools/bin/x86_64-linux-gnu-gcc 
-DHAVE_CONFIG_H -I. -I../../binutils/ld -I. -I../../binutils/ld -I../bfd 
-I../../binutils/ld/../bfd -I../../binutils/ld/../include -g -O2 
-DENABLE_PLUGINS -DLOCALEDIR=\"/tools/share/locale\" -g -O2 -g -O2 -MT 
libldtestplug_la-testplug.lo -MD -MP -MF .deps/libldtestplug_la-testplug.Tpo -c 
../../binutils/ld/testplug.c  -fPIC -DPIC -o .libs/libldtestplug_la-testplug.o
x86_64-linux-gnu-gcc: internal compiler error: Segmentation fault (program as)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[2]: *** [libldtestplug_la-testplug.lo] Error 1
make[2]: Leaving directory `/src/binutils-build/ld'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/src/binutils-build/ld'
make: *** [all] Error 2
make: Leaving directory `/src/binutils-build/ld'
dev@dev-VirtualBox /mnt/erraticOS/usr/src/binutils-build $ 

last week I got so sick of trying to fix it that I substituted ld from my OS 
which allowed me to get past this somehow but then I decided probably not such 
a great idea and came back to this, still nfc how to fix it. 



On Nov 14, 2012, at 12:01 AM, Kaleb van Ingen Schenau 
 wrote:

> Hello,
> 
> I'm having a bit of a problem which is stopping me from continueing with LFS, 
> after chapter 6.10 "Adjusting the Toolchain" i run the sanity check and all 
> results come out as they are supposed to be according to the book.
> 
> But after i install Binutils MPFR, MPC, GMP, ZLIB, FILE and Gcc (not in that 
> order) the results of the test discribed in the install/compile section of 
> GCC dont come out as they are supposed to be when i run:
> #echo 'main(){}' > dummy.c
> #cc dummy.c -v -Wl,--verbose &> dummy.log
> #readelf -l a.out | grep ': /lib'
> 
> i get : [Requesting program interpreter: /lib/ld-linux.so.2] which is intented
> when i then run :
> #grep -o '/usr/lib.*/crt[1in].*succeeded' dummy.log
> it gives me:
> /usr/lib/crt1.o succeeded
> /usr/lib/crti.o succeeded
> /usr/lib/crtn.o succeeded
>  
> instead of the intended:
> /usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../crt1.o succeeded
> /usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../crti.o succeeded
> /usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../crtn.o succeeded
> 
> Then when i run :
> #grep -B4 '^ /usr/include' dummy.log
> 
> it states:
> Ignoring nonexistent directory 
> "/tools/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../../i686-pc-linux-gnu/include
> Ignoring duplicate directory "/tools/include"
> #include "..." search starts here:
> #include <...> search starts here:
> /usr/include
> 
> Then when i run:
> #grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g' 
> SEARCH_DIR("/tools/i686-pc-linux-gnu/lib")
> SEARCH_DIR("/usr/lib")
> SEARCH_DIR("/lib");
> 
> which is also not correct
> 
> #grep "/lib.*/libc.so.6 " dummy.log
> and
> #grep found dummy.log
> DO come up with the correct output
> 
> This is the link to dummy.log: 
> pastebin.com/dCjzz5yb
> 
> Hope this helps and someone can shed some light on what part im messing up on 
> between 6.10 and 6.17
> 
> -- 
> http://linuxfromscratch.org/mailman/listinfo/lfs-support
> FAQ: http://www.linuxfromscratch.org/lfs/faq.html
> Unsubscribe: See the above information page

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page