Implement sanity check for the spec file edit(s)

[greg@…]

The lack of spec file edit will be the number 1 failure point for new readers of the book. We have seen this lots in the post plfs hint period. I propose that we put in a BIG FAT WARNING in the "Locking in Glibc" section. The test could be as simple as something like this:-

$ echo 'main(){}' > dummy.c $ gcc dummy.c $ readelf -l a.out | grep tools

If there is no ouput then something went wrong and the user MUST be told to STOP and fix up the mistake before continuing.

The same will be true (but in reverse) in Ch 6 so we really should do something there as well.

I'll commit something appropriate then seek comment. But if you have any concerns in the meanwhile then pls add them to this bug. Thanks.

[lfsbill@…]

Only one thought - may be bogus. IIRC, there are potentially multiple occurences of the modified string. Is it sufficient to just say "if no output" or "if some output" in the respective chapters? Is a line count or pharase about arch needed?

[greg@…]

Bill, the use of "readelf -l" as opposed to the old "readelf -a" greatly reduces the chances of bogus matches. I also ended up using a slightly better regexp than the one in this bugzilla entry.

readelf -l a.out | grep ': /tools'

and

readelf -l a.out | grep ': /lib'

Still not perfect :) But acceptable (I think!)

Try it out to see what I mean.

[lfsbill@…]

Just finished updating to latest sources and patches today. Will start a test build later and expect that your changes will have resolved the concern. Will post again if anything catches my eye. Thanks.

[greg@…]

The sanity checks have been in for a while now. No major howls of protest so I think they are serving the purpose. Closing.