Revisit binutils ldscripts treatment

[greg@…]

The way we currently handle the ldscripts is not ideal. Having to keep around the build dir is error prone and generally inconvenient. The last time I looked at this, it was apparent to me that what we are doing is just being overly anal. I will need to research and test this some more and also consult with Ryan. Also need to get to the bottom of how the compiled in ldscripts impact on the situation. Will probably get to this after the 5.0 book release.

[greg@…]

I did some work on this. These posts are relevant for the record:-

​http://linuxfromscratch.org/pipermail/lfs-dev/2003-September/038228.html ​http://linuxfromscratch.org/pipermail/lfs-dev/2003-September/038277.html ​http://linuxfromscratch.org/pipermail/lfs-dev/2003-September/038303.html

I ended up committing the changes so that we now do "make -C ld install" instead of "make -C ld install-data-local". In other words, we now install an adjusted linker instead of merely the adjusted linker scripts.

Leaving bug open for now. Would like to guage the feedback (if any) on keeping the binutils-build dirs around which seems to upset some people.

Am also looking at other solutions as per here:-

​http://linuxfromscratch.org/pipermail/lfs-dev/2003-September/038340.html

[gerard@…]

Any progress on this?

[greg@…]

We now have some notes in the book that deal with the reader forgetting to retain the binutils-build dirs. The bottom line is that it's not a huge drama if that happens. The user just ignores the command to install the adjusted linker with little risk of problem.

I'm still thinking of ways to fix this better. One potential way is to manually install a copy of ld into a directory that is earlier in GCC's search patch i.e. the output of 'gcc -print-search-dirs'. It will show up when doing 'gcc -print-prog-name=ld'. That way, we could just keep the original ld, use it, rename to *.old, install a new one, use it, rename the original back. Or something like that...

This will have to wait for a later date, at which time I'll reopen this bug. Closing.