Perl script enhancement when readjusting the toolchain

[hugo@…]

In the section "6.12. Readjusting the toolchain":

If that perl script is called more than one time:

perl -pi -e 's@ /tools/lib/ld-linux.so.2@ /lib/ld-linux.so.2@g;' \

-e 's@\*startfile_prefix_spec:\n@$_/usr/lib/@g;' \ gcc --print-file specs

The resulting specs file will look like this:

*startfile_prefix_spec: /usr/libusr/lib/

Which gives the error

/tools/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../i686-pc-linux-gnu/bin/ld:

crt1.o: No such file: No such file or directory

collect2: ld returned 1 exit status

If we add a space after the /usr/lib/ part in the perl script, it takes care of the problem (although the same directory can still be present multiple times):

perl -pi -e 's@ /tools/lib/ld-linux.so.2@ /lib/ld-linux.so.2@g;' \

-e 's@\*startfile_prefix_spec:\n@$_/usr/lib/ @g;' \ gcc --print-file specs

[jim@…]

Test file

[jim@…]

The issue was not with the perl, most of the problem was caused by a bad symlink. Here is the corrected version from the chapter before the perl sed

ln -s /tools/lib/libgcc_s.so{,.1} /usr/lib

The old one was missing the{,.1}

I have run this command on 2 different architectures, with the same file result.

*startfile_prefix_spec: /usr/lib/

I have attached a file I would like you to run and return to me, so I can validate the bug.

Using the following to test for the error perl -pi -e 's@\*startfile_prefix_spec:\n@$_/usr/lib/@g;' test

[jim@…]

Ok, I mis-read what the intent of the message. Sorry.

The perl enchancement is one option we could take, but I will recommand the following statement be added to the chapter06/readjusting.xml file instead.

<warning><para><emphasis>Do not</emphasis> run the following command more than once, it will adversely affect the outcome of software built after this step.</para></warning>

Assigning to Matt for final resolutions

[Matthew Burgess]

I don't see any problems with changing the perl script. Whilst I'd normally doubt the usefulness of protecting folks from running things twice and hitting errors - as this is to do with the toolchain adjustment I'm going to make an exception. We really don't want folks to screw that bit up - if this helps them avoid such problems then that's more than fine by me.

[Matthew Burgess]

Thanks for the report Hugo, I've made the suggested change to the unstable version of the book.