Re: [lfs-support] Adjusting the Toolchain: components with '-linux-gnu' should be ignored
See below: On 2/16/2018 2:40 PM, René Nyffenegger wrote: I am actually pretty convinced that I goofed up something. Like you, I am trying to create my repeatable scripts. Now, it's one thing to know that I am wrong, but a completely different thing to determine why I am wrong. So, I am still trying to figure out where the GCC compilation process takes the information from what will constitute the SEARCH_DIRS in the produced compiler suite. I might have come a step closer to solve my problem I *believe* that Step 6.16 (of LFS 8.1), described in http://www.linuxfromscratch.org/lfs/view/stable/chapter06/binutils.html, should build a /usr/bin/ld executable. This was not the case on my system. But the step built /usr/bin/addr2line, /usr/bin/ar, /usr/bin/as etc. Can someone confirm that such a /usr/bin/ld should indeed have been created with this step? Here is the list of file that was built on my system from the chapter 6 binutils build: /usr/bin/addr2line /usr/bin/ar /usr/bin/as /usr/bin/c++filt /usr/bin/dwp /usr/bin/elfedit /usr/bin/gprof /usr/bin/ld /usr/bin/ld.bfd /usr/bin/ld.gold /usr/bin/nm /usr/bin/objcopy /usr/bin/objdump /usr/bin/ranlib /usr/bin/readelf /usr/bin/size /usr/bin/strings /usr/bin/strip /usr/include/ansidecl.h /usr/include/bfd.h /usr/include/bfdlink.h /usr/include/dis-asm.h /usr/include/plugin-api.h /usr/include/symcat.h /usr/lib/ldscripts/elf32_x86_64.x /usr/lib/ldscripts/elf32_x86_64.xbn /usr/lib/ldscripts/elf32_x86_64.xc /usr/lib/ldscripts/elf32_x86_64.xd /usr/lib/ldscripts/elf32_x86_64.xdc /usr/lib/ldscripts/elf32_x86_64.xdw /usr/lib/ldscripts/elf32_x86_64.xn /usr/lib/ldscripts/elf32_x86_64.xr /usr/lib/ldscripts/elf32_x86_64.xs /usr/lib/ldscripts/elf32_x86_64.xsc /usr/lib/ldscripts/elf32_x86_64.xsw /usr/lib/ldscripts/elf32_x86_64.xu /usr/lib/ldscripts/elf32_x86_64.xw /usr/lib/ldscripts/elf_i386.x /usr/lib/ldscripts/elf_i386.xbn /usr/lib/ldscripts/elf_i386.xc /usr/lib/ldscripts/elf_i386.xd /usr/lib/ldscripts/elf_i386.xdc /usr/lib/ldscripts/elf_i386.xdw /usr/lib/ldscripts/elf_i386.xn /usr/lib/ldscripts/elf_i386.xr /usr/lib/ldscripts/elf_i386.xs /usr/lib/ldscripts/elf_i386.xsc /usr/lib/ldscripts/elf_i386.xsw /usr/lib/ldscripts/elf_i386.xu /usr/lib/ldscripts/elf_i386.xw /usr/lib/ldscripts/elf_iamcu.x /usr/lib/ldscripts/elf_iamcu.xbn /usr/lib/ldscripts/elf_iamcu.xc /usr/lib/ldscripts/elf_iamcu.xd /usr/lib/ldscripts/elf_iamcu.xdc /usr/lib/ldscripts/elf_iamcu.xdw /usr/lib/ldscripts/elf_iamcu.xn /usr/lib/ldscripts/elf_iamcu.xr /usr/lib/ldscripts/elf_iamcu.xs /usr/lib/ldscripts/elf_iamcu.xsc /usr/lib/ldscripts/elf_iamcu.xsw /usr/lib/ldscripts/elf_iamcu.xu /usr/lib/ldscripts/elf_iamcu.xw /usr/lib/ldscripts/elf_k1om.x /usr/lib/ldscripts/elf_k1om.xbn /usr/lib/ldscripts/elf_k1om.xc /usr/lib/ldscripts/elf_k1om.xd /usr/lib/ldscripts/elf_k1om.xdc /usr/lib/ldscripts/elf_k1om.xdw /usr/lib/ldscripts/elf_k1om.xn /usr/lib/ldscripts/elf_k1om.xr /usr/lib/ldscripts/elf_k1om.xs /usr/lib/ldscripts/elf_k1om.xsc /usr/lib/ldscripts/elf_k1om.xsw /usr/lib/ldscripts/elf_k1om.xu /usr/lib/ldscripts/elf_k1om.xw /usr/lib/ldscripts/elf_l1om.x /usr/lib/ldscripts/elf_l1om.xbn /usr/lib/ldscripts/elf_l1om.xc /usr/lib/ldscripts/elf_l1om.xd /usr/lib/ldscripts/elf_l1om.xdc /usr/lib/ldscripts/elf_l1om.xdw /usr/lib/ldscripts/elf_l1om.xn /usr/lib/ldscripts/elf_l1om.xr /usr/lib/ldscripts/elf_l1om.xs /usr/lib/ldscripts/elf_l1om.xsc /usr/lib/ldscripts/elf_l1om.xsw /usr/lib/ldscripts/elf_l1om.xu /usr/lib/ldscripts/elf_l1om.xw /usr/lib/ldscripts/elf_x86_64.x /usr/lib/ldscripts/elf_x86_64.xbn /usr/lib/ldscripts/elf_x86_64.xc /usr/lib/ldscripts/elf_x86_64.xd /usr/lib/ldscripts/elf_x86_64.xdc /usr/lib/ldscripts/elf_x86_64.xdw /usr/lib/ldscripts/elf_x86_64.xn /usr/lib/ldscripts/elf_x86_64.xr /usr/lib/ldscripts/elf_x86_64.xs /usr/lib/ldscripts/elf_x86_64.xsc /usr/lib/ldscripts/elf_x86_64.xsw /usr/lib/ldscripts/elf_x86_64.xu /usr/lib/ldscripts/elf_x86_64.xw /usr/lib/ldscripts/i386linux.x /usr/lib/ldscripts/i386linux.xbn /usr/lib/ldscripts/i386linux.xn /usr/lib/ldscripts/i386linux.xr /usr/lib/ldscripts/i386linux.xu /usr/lib/libbfd-2.29.so /usr/lib/libbfd.a /usr/lib/libbfd.so /usr/lib/libopcodes-2.29.so /usr/lib/libopcodes.a /usr/lib/libopcodes.so /usr/share/info/as.info /usr/share/info/bfd.info /usr/share/info/binutils.info /usr/share/info/gprof.info /usr/share/info/ld.info /usr/share/locale/bg/LC_MESSAGES/binutils.mo /usr/share/locale/bg/LC_MESSAGES/gprof.mo /usr/share/locale/bg/LC_MESSAGES/ld.mo /usr/share/locale/ca/LC_MESSAGES/binutils.mo /usr/share/locale/da/LC_MESSAGES/bfd.mo /usr/share/locale/da/LC_MESSAGES/binutils.mo /usr/share/locale/da/LC_MESSAGES/gprof.mo /usr/share/locale/da/LC_MESSAGES/ld.mo /usr/share/locale/da/LC_MESSAGES/opcodes.mo /usr/share/locale/de/LC_MESSAGES/gprof.mo /usr/share/locale/de/LC_MESSAGES/ld.mo /usr/share/locale/de/LC_MESSAGES/opcodes.mo /usr/share/locale/eo/LC_MESSAGES/gprof.mo /usr/share/locale/es/LC_MESSAGES/bfd.mo /usr/share/locale/es/LC_MESSAGES/binutils.mo
Re: [lfs-support] Adjusting the Toolchain: components with '-linux-gnu' should be ignored
I am actually pretty convinced that I goofed up something. Like you, I am trying to create my repeatable scripts. Now, it's one thing to know that I am wrong, but a completely different thing to determine why I am wrong. So, I am still trying to figure out where the GCC compilation process takes the information from what will constitute the SEARCH_DIRS in the produced compiler suite. I might have come a step closer to solve my problem I *believe* that Step 6.16 (of LFS 8.1), described in http://www.linuxfromscratch.org/lfs/view/stable/chapter06/binutils.html, should build a /usr/bin/ld executable. This was not the case on my system. But the step built /usr/bin/addr2line, /usr/bin/ar, /usr/bin/as etc. Can someone confirm that such a /usr/bin/ld should indeed have been created with this step? -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] Adjusting the Toolchain: components with '-linux-gnu' should be ignored
I am afraid I have to bother you again with theser SEARCH_DIRs.
While the question above pertained to step 6.10, I now have a similar
thing in Step 6.20 (Installation of GCC)
SEARCH_DIR("=/tools/x86_64-pc-linux-gnu/lib64")
SEARCH_DIR("/usr/lib")
SEARCH_DIR("/lib")
SEARCH_DIR("=/tools/x86_64-pc-linux-gnu/lib"
Because this will, as I believe, the final GCC for LFS, there should
not be
any /tools reference at all.
Also of course, the book also mentions much more directories like lib64
and the various $(uname -m) directories.
I am not sure what GCC is supposed to search in these directories,
but I assume
that it is for shared libraries that are not specified with -L to the
linker.
Anyway, when GCC is compiled, from where does ./configure(? or the
compile process) take the information
which SEARCH_DIRs it compiles into its binary/binaries(?). If I knew
that, I could go back
to the respective point in my build and go on from there again.
The above was from 6.10
Ok the below is what you should get from 6.20
If you get something other than this you may indeed have missed
something or something has gone wrong.
I script my builds because I know I will screw up. Just ask my wife
she will tell you how much and how often I screw up! According to her
she is the only thing that keeps me from becoming a complete mess.
I can review each step and see what stupid thing I did and fix it.
Then I can wipe out the /mnt/lfs and run the script to start over.
That makes sure something did not get over looked only to come back
and bite me.
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
Book: [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/crt1.o succeeded
/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/crti.o succeeded
/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/crtn.o succeeded
Book: /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/crt1.o
succeeded
Book: /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/crti.o
succeeded
Book: /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/crtn.o
succeeded
#include <...> search starts here:
/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/include
/usr/local/include
/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/include-fixed
/usr/include
Book: #include <...> search starts here:
Book: /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/include
Book: /usr/local/include
Book: /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/include-fixed
Book: /usr/include
SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib64")
SEARCH_DIR("/usr/local/lib64")
SEARCH_DIR("/lib64")
SEARCH_DIR("/usr/lib64")
SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib")
SEARCH_DIR("/usr/local/lib")
SEARCH_DIR("/lib")
SEARCH_DIR("/usr/lib");
Book: SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib64")
Book: SEARCH_DIR("/usr/local/lib64")
Book: SEARCH_DIR("/lib64")
Book: SEARCH_DIR("/usr/lib64")
Book: SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib")
Book: SEARCH_DIR("/usr/local/lib")
Book: SEARCH_DIR("/lib")
Book: SEARCH_DIR("/usr/lib");
dummy.log:attempt to open /lib/libc.so.6 succeeded
dummy.log:attempt to open /lib/libc.so.6 succeeded
Book: attempt to open /lib/libc.so.6 succeeded
found ld-linux-x86-64.so.2 at /lib/ld-linux-x86-64.so.2
Book: found ld-linux-x86-64.so.2 at /lib/ld-linux-x86-64.so.2
removed 'dummy.c'
removed 'a.out'
removed 'dummy.log'
I am actually pretty convinced that I goofed up something. Like you, I
am trying to create my repeatable scripts.
Now, it's one thing to know that I am wrong, but a completely different
thing to determine why I am wrong.
So, I am still trying to figure out where the GCC compilation process
takes the information from what will constitute the
SEARCH_DIRS in the produced compiler suite.
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Do not top post on this list.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] Adjusting the Toolchain: components with '-linux-gnu' should be ignored
On 2/15/2018 10:58 AM, René Nyffenegger wrote:
On 02/15/2018 01:54 PM, Baho Utot wrote:
On 2/15/2018 5:51 AM, René Nyffenegger wrote:
As I am proceeding with building LFS, I am now in Step 6.10,
Adjusting the Toolchain.
The book instructs me to
grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g' On my system, the
output is:
SEARCH_DIR("=/tools/x86_64-pc-linux-gnu/lib64")
SEARCH_DIR("/usr/lib")
SEARCH_DIR("/lib")
SEARCH_DIR("=/tools/x86_64-pc-linux-gnu/lib")
Although the book tells me to ignore components with '-linux-gnu', I
am still
a bit worried about the paths that start with /tools. I just want to
be 100% positive
about going on with my build process.
So, the question is: can I ignore these -linux-gnu search strings
ALTHOUGH they start with /tools?
This is what my build produces, the Output lines are from the Book and
what you should be looking for. The lines not prefixed by Output: are
the actual lines from the test. I believe you are good to go. The
"real" test comes after gcc. That is the one that gave me the most
grief. Since I am doing scripted builds and I failed to remove the
gcc symlink the install process got all balled up.
Output: [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
Output: /usr/lib/../lib/crt1.o succeeded
Output: /usr/lib/../lib/crti.o succeeded
Output: /usr/lib/../lib/crtn.o succeeded
/usr/lib/../lib/crt1.o succeeded
/usr/lib/../lib/crti.o succeeded
/usr/lib/../lib/crtn.o succeeded
Output: #include <...> search starts here:
Output: /usr/include
#include <...> search starts here:
/usr/include
Output: SEARCH_DIR(/usr/lib)
Output: SEARCH_DIR(/lib)
SEARCH_DIR("=/tools/x86_64-pc-linux-gnu/lib64")
SEARCH_DIR("/usr/lib")
SEARCH_DIR("/lib")
SEARCH_DIR("=/tools/x86_64-pc-linux-gnu/lib");
Output: attempt to open /lib/libc.so.6 succeeded
attempt to open /lib/libc.so.6 succeeded
Output: found ld-linux-x86-64.so.2 at /lib/ld-linux-x86-64.so.2
found ld-linux-x86-64.so.2 at /lib/ld-linux-x86-64.so.2
removed 'dummy.c'
removed 'a.out'
removed 'dummy.log'
I am afraid I have to bother you again with theser SEARCH_DIRs.
While the question above pertained to step 6.10, I now have a similar
thing in Step 6.20 (Installation of GCC)
SEARCH_DIR("=/tools/x86_64-pc-linux-gnu/lib64")
SEARCH_DIR("/usr/lib")
SEARCH_DIR("/lib")
SEARCH_DIR("=/tools/x86_64-pc-linux-gnu/lib"
Because this will, as I believe, the final GCC for LFS, there should not be
any /tools reference at all.
Also of course, the book also mentions much more directories like lib64
and the various $(uname -m) directories.
I am not sure what GCC is supposed to search in these directories, but I
assume
that it is for shared libraries that are not specified with -L to the
linker.
Anyway, when GCC is compiled, from where does ./configure(? or the
compile process) take the information
which SEARCH_DIRs it compiles into its binary/binaries(?). If I knew
that, I could go back
to the respective point in my build and go on from there again.
The above was from 6.10
Ok the below is what you should get from 6.20
If you get something other than this you may indeed have missed
something or something has gone wrong.
I script my builds because I know I will screw up. Just ask my wife she
will tell you how much and how often I screw up! According to her she is
the only thing that keeps me from becoming a complete mess.
I can review each step and see what stupid thing I did and fix it. Then
I can wipe out the /mnt/lfs and run the script to start over. That
makes sure something did not get over looked only to come back and bite me.
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
Book: [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/crt1.o succeeded
/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/crti.o succeeded
/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/crtn.o succeeded
Book: /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/crt1.o
succeeded
Book: /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/crti.o
succeeded
Book: /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/crtn.o
succeeded
#include <...> search starts here:
/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/include
/usr/local/include
/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/include-fixed
/usr/include
Book: #include <...> search starts here:
Book: /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/include
Book: /usr/local/include
Book: /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/include-fixed
Book: /usr/include
SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib64")
SEARCH_DIR("/usr/local/lib64")
SEARCH_DIR("/lib64")
SEARCH_DIR("/usr/lib64")
SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib")
SEARCH_DIR("/usr/local/lib")
SEARCH_DIR("/lib")
SEARCH_DIR("/usr/lib");
Book: SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib64")
Book:
Re: [lfs-support] Adjusting the Toolchain: components with '-linux-gnu' should be ignored
On 02/15/2018 01:54 PM, Baho Utot wrote:
On 2/15/2018 5:51 AM, René Nyffenegger wrote:
As I am proceeding with building LFS, I am now in Step 6.10,
Adjusting the Toolchain.
The book instructs me to
grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g' On my system, the
output is:
SEARCH_DIR("=/tools/x86_64-pc-linux-gnu/lib64")
SEARCH_DIR("/usr/lib")
SEARCH_DIR("/lib")
SEARCH_DIR("=/tools/x86_64-pc-linux-gnu/lib")
Although the book tells me to ignore components with '-linux-gnu', I
am still
a bit worried about the paths that start with /tools. I just want to
be 100% positive
about going on with my build process.
So, the question is: can I ignore these -linux-gnu search strings
ALTHOUGH they start with /tools?
This is what my build produces, the Output lines are from the Book and
what you should be looking for. The lines not prefixed by Output: are
the actual lines from the test. I believe you are good to go. The
"real" test comes after gcc. That is the one that gave me the most
grief. Since I am doing scripted builds and I failed to remove the
gcc symlink the install process got all balled up.
Output: [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
Output: /usr/lib/../lib/crt1.o succeeded
Output: /usr/lib/../lib/crti.o succeeded
Output: /usr/lib/../lib/crtn.o succeeded
/usr/lib/../lib/crt1.o succeeded
/usr/lib/../lib/crti.o succeeded
/usr/lib/../lib/crtn.o succeeded
Output: #include <...> search starts here:
Output: /usr/include
#include <...> search starts here:
/usr/include
Output: SEARCH_DIR(/usr/lib)
Output: SEARCH_DIR(/lib)
SEARCH_DIR("=/tools/x86_64-pc-linux-gnu/lib64")
SEARCH_DIR("/usr/lib")
SEARCH_DIR("/lib")
SEARCH_DIR("=/tools/x86_64-pc-linux-gnu/lib");
Output: attempt to open /lib/libc.so.6 succeeded
attempt to open /lib/libc.so.6 succeeded
Output: found ld-linux-x86-64.so.2 at /lib/ld-linux-x86-64.so.2
found ld-linux-x86-64.so.2 at /lib/ld-linux-x86-64.so.2
removed 'dummy.c'
removed 'a.out'
removed 'dummy.log'
I am afraid I have to bother you again with theser SEARCH_DIRs.
While the question above pertained to step 6.10, I now have a similar
thing in Step 6.20 (Installation of GCC)
SEARCH_DIR("=/tools/x86_64-pc-linux-gnu/lib64")
SEARCH_DIR("/usr/lib")
SEARCH_DIR("/lib")
SEARCH_DIR("=/tools/x86_64-pc-linux-gnu/lib"
Because this will, as I believe, the final GCC for LFS, there should not be
any /tools reference at all.
Also of course, the book also mentions much more directories like lib64
and the various $(uname -m) directories.
I am not sure what GCC is supposed to search in these directories, but I assume
that it is for shared libraries that are not specified with -L to the linker.
Anyway, when GCC is compiled, from where does ./configure(? or the compile
process) take the information
which SEARCH_DIRs it compiles into its binary/binaries(?). If I knew that, I
could go back
to the respective point in my build and go on from there again.
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Do not top post on this list.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] Adjusting the Toolchain: components with '-linux-gnu' should be ignored
On 2/15/2018 5:51 AM, René Nyffenegger wrote:
As I am proceeding with building LFS, I am now in Step 6.10, Adjusting
the Toolchain.
The book instructs me to
grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g' On my system, the
output is:
SEARCH_DIR("=/tools/x86_64-pc-linux-gnu/lib64")
SEARCH_DIR("/usr/lib")
SEARCH_DIR("/lib")
SEARCH_DIR("=/tools/x86_64-pc-linux-gnu/lib")
Although the book tells me to ignore components with '-linux-gnu', I am
still
a bit worried about the paths that start with /tools. I just want to be
100% positive
about going on with my build process.
So, the question is: can I ignore these -linux-gnu search strings
ALTHOUGH they start with /tools?
This is what my build produces, the Output lines are from the Book and
what you should be looking for. The lines not prefixed by Output: are
the actual lines from the test. I believe you are good to go. The
"real" test comes after gcc. That is the one that gave me the most
grief. Since I am doing scripted builds and I failed to remove the gcc
symlink the install process got all balled up.
Output: [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
Output: /usr/lib/../lib/crt1.o succeeded
Output: /usr/lib/../lib/crti.o succeeded
Output: /usr/lib/../lib/crtn.o succeeded
/usr/lib/../lib/crt1.o succeeded
/usr/lib/../lib/crti.o succeeded
/usr/lib/../lib/crtn.o succeeded
Output: #include <...> search starts here:
Output: /usr/include
#include <...> search starts here:
/usr/include
Output: SEARCH_DIR(/usr/lib)
Output: SEARCH_DIR(/lib)
SEARCH_DIR("=/tools/x86_64-pc-linux-gnu/lib64")
SEARCH_DIR("/usr/lib")
SEARCH_DIR("/lib")
SEARCH_DIR("=/tools/x86_64-pc-linux-gnu/lib");
Output: attempt to open /lib/libc.so.6 succeeded
attempt to open /lib/libc.so.6 succeeded
Output: found ld-linux-x86-64.so.2 at /lib/ld-linux-x86-64.so.2
found ld-linux-x86-64.so.2 at /lib/ld-linux-x86-64.so.2
removed 'dummy.c'
removed 'a.out'
removed 'dummy.log'
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Do not top post on this list.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
http://en.wikipedia.org/wiki/Posting_style
[lfs-support] Adjusting the Toolchain: components with '-linux-gnu' should be ignored
As I am proceeding with building LFS, I am now in Step 6.10, Adjusting the
Toolchain.
The book instructs me to
grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g' On my system, the
output is:
SEARCH_DIR("=/tools/x86_64-pc-linux-gnu/lib64")
SEARCH_DIR("/usr/lib")
SEARCH_DIR("/lib")
SEARCH_DIR("=/tools/x86_64-pc-linux-gnu/lib")
Although the book tells me to ignore components with '-linux-gnu', I am still
a bit worried about the paths that start with /tools. I just want to be 100%
positive
about going on with my build process.
So, the question is: can I ignore these -linux-gnu search strings ALTHOUGH they
start with /tools?
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Do not top post on this list.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
http://en.wikipedia.org/wiki/Posting_style
[lfs-support] Adjusting the Toolchain
I'm just in the process of running over (and modifying) my build scripts. I'm currently looking at "Adjusting the Toolchain", chapter 6.10 in the current stable book, and a question arose in my mind. Wouldn't it be better to copy ld-new rather than move it? Doing so would keep ld-new around in case something went wrong with the build beyond that point, after all, we do rebuild binutils a little later. I know that there is the suggestion at the end of chapter 5 of making a backup of the /tools directory, but I'm sure that many don't. Maybe I'm wrong, or have missed something (entirely possible) so answers would be appreciated. Richard -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
