[Bug 895] Incorrect startfiles linked in during ch6 toolchain lock in.

bugzilla at linuxfromscratch.org bugzilla at linuxfromscratch.org
Tue Sep 7 19:20:41 PDT 2004


http://bugs.linuxfromscratch.org/show_bug.cgi?id=895





------- Additional Comments From ryan.oliver at pha.com.au  2004-09-07 20:20 -------
Okay, final analysis done.

Problem is consistent with the initial estimation of the problem.
1: current build method we link in the wrong startfiles
2: if you don't install the adjusted linker during the lock in you will
   link in libc etc from /tools .

In future to avoid the run-around we should probably ignore bug reports
from non-lfs builds.

Finished the build with the full startfile spec mods from start to finish
and there was no linking against /tools libraries, and the correct startfiles
were linked in.

Another thing I noticed was that startfile_prefix_spec mods doesn't behave
exactly as I expected it to when it is pointed outside of the prefix gcc
was installed into (have to go back and look over the code), the only -L
search paths that will appear point _only_ under the gcc and binutils
install trees. No -L/tools/lib or -L/usr/lib . Here it is in the hands of 
the (internal) linker scripts to locate the shared libraries.

Looking at it, for uni-arch builds, the only real mod we should have to do
is to define startfile_prefix_spec during the ch6 specs modifications
to /usr/lib/ .

This takes care of the startfiles, adjusted ch5 linker takes care of linking
in the correct libraries.

This minimal (one line) fix to the current book hasn't been tested (I used the
new specs patch, so have invalidated that as a test), but should work.

If someone could test this (it will take me a bit) and stop after the ch6
lock-in and build a test program 
( gcc -v -Wl,--verbose -o foo foo.c > ch6-lockin-tc-test 2>&1 ) I'd 
appreciate it. 

If everything goes as expected we can shelve the proposed specs patch
(will come in handy later if we decide to support bi-arch builds), and avoid
the ugly sed mods.

Note: we will still need to update the current LFS testing specs patch so
STANDARD_INCLUDE_DIR is overridden on all architectures...

Anyway, will attach a tarball of the gcc output from tests at various points
(build was LFS testing, with the specs patch with startfile_prefix_spec mod)
for reference soon.

BTW, thanks Anderson for the perl snippet ;-) Much neater :-)



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
You are the QA contact for the bug, or are watching the QA contact.



More information about the lfs-book mailing list