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

Paige Thompson erratic at devel.ws
Wed Nov 14 00:22:58 PST 2012


I found a quick fix for my problem, 

dev at 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 at dev-VirtualBox /mnt/erraticOS/tools/bin $ ldd ld-new 
        linux-vdso.so.1 =>  (0x00007fffd1fdc000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f24b10c6000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f24b0d09000)
        /tools/lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f24b12e0000)
dev at dev-VirtualBox /mnt/erraticOS/tools/bin $ ldd ld
        linux-vdso.so.1 =>  (0x00007fff3ad70000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fde0e3ce000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fde0e011000)
        /tools/lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007fde0e5e8000)
dev at 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 <erratic at devel.ws> wrote:

> hahahahah, thats funny, right as this email arrived I was trying to figure out the following (pass 2 of binutils): 
> 
> dev at 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 <http://gcc.gnu.org/bugs.html> 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 at 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 <k.ingen.schenau at gmail.com> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-support/attachments/20121114/be91c6d2/attachment.html>


More information about the lfs-support mailing list