Opened 21 years ago

Closed 20 years ago

#597 closed defect (fixed)

Revisit binutils ldscripts treatment

Reported by: greg@… Owned by: greg@…
Priority: lowest Milestone:
Component: Book Version: CVS
Severity: normal Keywords:
Cc:

Description

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.

Change History (4)

comment:1 by greg@…, 21 years ago

Status: newassigned

comment:2 by greg@…, 21 years ago

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

comment:3 by gerard@…, 20 years ago

Any progress on this?

comment:4 by greg@…, 20 years ago

Resolution: fixed
Status: assignedclosed

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.

Note: See TracTickets for help on using tickets.