Missing ld-new causes breakage in 5.7 Adjusting the Toolchain

[peterennis@…]

If the test for toolchain adjustment is repeated for whatever reason, then it will break.

Those interested in possible reasons please open a new ticket, discuss on IRC, chat, etc.

[peter]

A minimum test case is provided in the attachment. Below is the interaction of the test case:

Linux From Scratch Version SVN-20060414 5.7. Adjusting the Toolchain !!!CAUTION!!!

[developer@lfs ~]$ ls -l total 20 drwxr-xr-x 6 developer developer 4096 Apr 15 13:59 Desktop drwxrwxr-x 3 developer developer 4096 Apr 16 09:35 ld-test -rw-rw-r-- 1 developer developer 10240 Apr 16 09:36 ld-test.tar [developer@lfs ~]$ cd ld-test [developer@lfs ld-test]$ ls copy-of-original-ld gccdumpmachine ld ld-new mvtest1 mvtest2 mvtest3 [developer@lfs ld-test]$ cat ld the ORIGINAL ld file [developer@lfs ld-test]$ cat ld-new the NEW ld file [developer@lfs ld-test]$ ls copy-of-original-ld gccdumpmachine ld ld-new mvtest1 mvtest2 mvtest3 [developer@lfs ld-test]$ ./mvtest1 ./ld' -> ./ld-old' [developer@lfs ld-test]$ ls copy-of-original-ld gccdumpmachine ld-new ld-old mvtest1 mvtest2 mvtest3 [developer@lfs ld-test]$ ./mvtest2 ./ld-new' -> ./ld' [developer@lfs ld-test]$ ls copy-of-original-ld gccdumpmachine ld ld-old mvtest1 mvtest2 mvtest3 [developer@lfs ld-test]$ ./mvtest3 create symbolic link ./gccdumpmachine/ld' to ./ld' [developer@lfs ld-test]$ ls copy-of-original-ld gccdumpmachine ld ld-old mvtest1 mvtest2 mvtest3 [developer@lfs ld-test]$ ./mvtest1 ./ld' -> ./ld-old' [developer@lfs ld-test]$ ./mvtest2 mv: cannot stat `./ld-new': No such file or directory [developer@lfs ld-test]$ ./mvtest3 ln: `./gccdumpmachine/ld': File exists [developer@lfs ld-test]$ which ld !!!!!!!!!!!!!!!!!!!!!!!!! /usr/bin/ld !!!!!!!!!!!!!!!!!!!!!!!!! [developer@lfs ld-test]$ ls copy-of-original-ld gccdumpmachine ld-old mvtest1 mvtest2 mvtest3 [developer@lfs ld-test]$ cat ld-old the NEW ld file [developer@lfs ld-test]$

NOTE: readelf will show the correct result of: [Requesting program interpreter: /tools/lib/ld-linux.so.2] but the host ld will be used as shown by the which ld output above.

Proposed Solution =================

1. Use appropriate cp and rm command instead of mv

so that ld-new and ld-old remain.

2. Include the which ld test in the caution as a

requirement. By itself the readelf test is insufficient and misleading in this case.

[peter]

I copied and pasted the interaction for the test case and it appears the formatting is messed up by trac. This could be a bug, feature, PEBKAC or RTFM. It is, however, not a problem I have experienced before with using various bugzillas. Should such text be posted as Wikiformatting? If so, then some instruction up front would help.

[peter]

test case output that is not messed up with trac formatting

[dbn.lists@…]

1. You are not supposed to keep running the Adjustment.

2. Would it be possible to expand upon the proposed solution? I'm not following it.

3. which ld is not reliable and has nothing to do with ld-linux.so.2. There are two different ld's. ld is rarely if ever called directly. gcc almost always invokes it.

[peter]

1. "not supposed" is a lead in to a (potentially) pointless discussion

on why users do things. If repeating the adjustemnt process causes breakage then it deserves some warning that it is a one-shot-deal.

2. cp ld-new ld

If the steps are repeated then this will at least remove the ld-new not found error that results from the mv commands. The ld-new and ld-old files can be left alone.

3. "almost always" is not absolute and leaves room for error.

I do not know enough about the toolchain and inner workings of gcc but I would prefer an "always" solution.

Is the error message for missing ld-new "mostly harmness"? The repeated process results in a missing ld-new, and an existing ld-old (that is actually ld-new) and no ld in /tools/bin. If nothing is broken, then it is, at the least, confusing (at least to me), and not optimal.

I do not know if continuing in this state will really break things later. The test case at least shows that I can rename the ld-old to ld (because it is the ld-new file) and continue.

[archaic@…]

Don't over dramatize this so-called problem. We will look into it.

[dbn.lists@…]

I agree that there should be a warning to not redo the actual ld adjustment. Although, the gcc specs adjustement can be repeated.

The problem with leaving ld-new around is that it's misleading as to which is referring to which. If ld-new is left around, you would have:

/tools/bin/{ld-old,ld,ld-new}
/tools/i686-pc-linux-gnu/bin/{ld-old,ld,ld-new}

I guess that's not so bad. After binutils-pass2 is installed, it would overwrite ld and ld-new.

Peter, this is a reliable test to see what ld (the dynamic loader from binutils as opposed to the dynamic linker from glibc, ld-linux.so.2) is doing.

$(gcc -print-prog-name=ld) --verbose | grep 'SEARCH'

[peter]

OK. Thanks for the update(s)

[Jeremy Huntwork]

1. Trac is a Wiki and it says up above the comment entry box that "you may use WikiFormatting here". Then it gives you nice Word-Processor-like buttons for quick formatting. One of them is a code block button.

    What you see
   is what
      you get
   !
   

2. From looking over the page again, and your test-case, I can only assume that what you're referring to as "break" is the errors you'll run into if you try to repeat the ld adjustments. In other words, mv will tell you no such file, and ln will say that the file exists. In both cases, nothing is broken, everything is still as it should be, and in effect, the errors are telling you that you've done those steps already.

Marking this as invalid because no harm at all comes from executing any of the commands over again in the adjusting sections and therefore not even a warning is necessary. (If you happened to create another ld-new with binutils that points somewhere else, place it in /tools/bin and then re-do the commands, well you'll probably mess something up.)

[schiffsratte]

I run into this prob today (while working on svn 20081023) I just didn't pay attention obviously as I have made a break at this point (which is not a good idea, maybe) and ended up without a ld-new at this point (6.10 I also did this step twice). As this topic so far didn't make it into the book as far as I can see, maybe as a hint, I'd like to mention that making binutils pass2 (5.12.1) again as lfs-user outside the chroot-env, with the preparations for the re-adjusting the toolchain as mentioned there, did the trick for me. After that I could finish chapter 6.10 without errors. Just as a hint for all those, who will run into this