id	summary	reporter	owner	description	type	status	priority	milestone	component	version	severity	resolution	keywords	cc
895	Incorrect startfiles linked in during ch6 toolchain lock in.	ryan.oliver@…	lfs-book@…	"Apologies if I've screwed up with assigning priority etc...

Issue reported over at 
http://www.diy-linux.org/pipermail/diy-linux-dev/2004-September/000122.html

Fix reported at
http://linuxfromscratch.org/pipermail/lfs-hackers/2004-September/002110.html

This isn't a great issue, for all intents and purposes the startfile objects
( crt[i1n].o ) created ch5 and ch6 will behave the same.

Anyway, to avoid this issue entirely we can specify exactly where our compiler
will look for startfiles in the specfile, specifically startfile_prefix_spec .

For current LFS builds this involves a change to the present gcc-3.4.1 patch
to add a definition for STARTFILE_PREFIX_SPEC into 
gcc/config/${ARCH}/{linux.h,linux64.h} forcing gcc to always look under
/tools/lib/ to locate the startfiles.

During the specfile edit ch6, we will have to edit the specfile so that
startfile_prefix_spec is defined as /usr/lib/ ensuring again the correct
startfiles get used.

This also has a side-effect, it ensures multi-lib builds of gcc will also
always be correct as the correct startfiles for the chosen architecture
will be used, as startfile_prefix_spec gets the multilib spec appended 
( ie: ../lib , ../lib64 ) . 

Other proposed fixes break the build of
multilib libgcc (if -B/path/to/lib is used, this is always first in
search path and doesn't get expanded with the multilib spec, hence you
end up with the situation where 32bit startfiles are used in the link of
64bit libgcc). This is out of scope for the present book, but worth noting.

A new gcc patch will have to be generated, and additional instructions added
during the specs edit.

Will generate a patch shortly, unless someone beats me to it ;-)"	defect	closed	normal		Book	TESTING	normal	fixed