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

bugzilla at linuxfromscratch.org bugzilla at linuxfromscratch.org
Thu Sep 2 21:33:24 PDT 2004


           Summary: Incorrect startfiles linked in during ch6 toolchain lock
           Product: Linux From Scratch
           Version: TESTING
          Platform: All
               URL: http://www.diy-linux.org/pipermail/diy-linux-dev/2004-
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: Book
        AssignedTo: lfs-book at linuxfromscratch.org
        ReportedBy: ryan.oliver at pha.com.au
         QAContact: lfs-book at linuxfromscratch.org

Apologies if I've screwed up with assigning priority etc...

Issue reported over at 

Fix reported at

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 ;-)

------- 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