Incorrect startfiles linked in during ch6 toolchain lock in.

[ryan.oliver@…]

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

[ryan.oliver@…]

The extent of the problem as described at diy-linux is limited to whatever they are doing different in regards to the non-linking of the new libc.a .

From checks on systems here collect2 does not introduce any library search paths which override the hard-coded linker search paths. collect2 adds the search paths required by gcc to locate its own libraries, or in the case of cross-compiling the target libraries under ${PREFIX}/${TARGET_ARCH}/lib .

I get the behaviour they see only if I dont install the previously built ld we created in chapter5 during the lock-in ch6.

For LFS this remains soley a bug with startfile selection.

Patch soon...

[ryan.oliver@…]

OK, required book fixes...

5.9. Adjusting the Toolchain No change here, we will pick up the correct startfiles .

5.13. GCC-3.4.1 - Pass 2 gcc-3.4.1-specs-1.patch needs to be updated to define STARTFILE_PREFIX_SPEC as /tools/lib/ .

This change won't appear to affect the build at all. It does make gcc check this spec though, which won't happen if it wasn't defined during the build (could be wrong here, I tend to always define it, quick test will show what happens) allowing us to override it ch6.

Will generate a patch sometime soon ;-)

6.12. Re-adjusting the Toolchain

"Next, amend the GCC specs file so that it points to the new dynamic linker. A sed command accomplishes this. We also need to ensure we use the newly created startfiles ( crt[i1n].o ) provided by glibc. We accomplish this by altering startfile_prefix_spec:

sed -i -e 's@ /tools/lib/ld-linux.so.2@ /lib/ld-linux.so.2@g' \

-e '/\*startfile_prefix_spec:/{

h n s@/tools@/usr@g x x }' gcc --print-file specs

(I havent tried this with -i yet)

Yes its an ugly sed, matches on one line then stuffs it in the hold space, grabs the next line into the pattern space and performs the mod, then spits out both lines. Only way to ensure the change is completely localised. May be being overly anal though...

[Matthew Burgess]

Ryan, I've changed the VERSION to SVN. Feel free to change it back to TESTING if you think it should block the LFS-6.0 release, from your previous comments I don't think it's serious enough an issue. Of course, I realise that "VERSION" should really be the version that the bug is reported against, which of course is TESTING. However, we don't have any entries in the "Target Milestone" field which is really where the "SVN" (or ideally LFS-6.1) should be denoted. Hmmm, who's maintaining bugzilla? Maybe this is more of a policy thing, but with multiple branches we really need to keep track of which branches (note the plural!) a bug applies to and which version of the book we expect/want to fix it in. A note to lfs-dev will be posted, just as soons as my rebuild is done :)

Cheers,

Matt.

[ryan.oliver@…]

I'd put this into testing... bug applies to all LFS versions > 5.0

I went back and checked my test boxes and my initial checks of the error were tainted due to my having already performed the startfile_prefix fix . ( Too many working directories :-/ apologies )

I went and did a vanilla LFS build. Indeed without the fix collect2 links in libraries from the wrong location.

As long as startfile_prefix_spec is modified when dynamic linker is modified we ensure that we always link against the correct libraries, and pull in the correct startfiles.

Very quick explanation at ​http://linuxfromscratch.org/pipermail/lfs-hackers/2004-September/002124.html

We will also want to change

5.9. Adjusting the Toolchain

sed -i -e 's@ /lib/ld-linux.so.2@ /tools/lib/ld-linux.so.2@g' \

-e '/\*startfile_prefix_spec:/{

h n s@^{$@/tools/lib/@g x x }' gcc --print-file specs}

Keeps things consistent...

Apologies for not generating the gcc specs patch yet, work keeps getting in the way :-/

[ryan.oliver@…]

interim specs patch for gcc-3.4.1

[ryan.oliver@…]

updated specs patch for gcc-3.4.1

[lizardo@…]

If that "interesting" sed line is still required (even with the patches you provided), I would suggest using perl for the substitution task to simplify things. The syntax is very similar to sed. See how the command you provided is done with perl: perl -pi -e 's@ /lib/ld-linux.so.2@ /tools/lib/ld-linux.so.2@g;' \

-e 's@\*startfile_prefix_spec:\n@$_/tools/lib/@g;' \ gcc --print-file specs

The "-p" option is what makes perl behave like sed.

[ryan.oliver@…]

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

[jeremy@…]

Ryan, if you could, at some point, post a simple summary of the command changes you suggest, all in one place, I'll see that they go into unstable.

-J-

[ryan.oliver@…]

bug_895-gcc_output.tar.bz2

[ryan.oliver@…]

Okay, it works with only the startfile_prefix_spec addition during the ch6 toolchain specs mods.

I have yet to manage to make this break...

How we do this in the book, preference goes to a slight mod of Anderson's perl snippet, but probably best to also give an example of the modified spec file so people can manually edit it if they so choose.

It should look like

*startfile_prefix_spec: /usr/lib/

*some other spec:

Note the trailing slash, and note that there must be exactly one blank line below (or else you will get a specs parse error)

Will post the tests from the latest cut soon, and will regenerate the specs patch

After that is done this will be changed to resolved...

J_Man, have you got enough to go on here? Let me know...

[jeremy@…]

OK, added a modified version of Anderson's perl statement into Unstable, which should fix this problem. We now get the following output after the chapter 6 locking of glibc:

root:/# echo 'main(){}' > dummy.c root:/# gcc dummy.c -Wl,--verbose 2>&1 | grep succeeded attempt to open /usr/lib/crt1.o succeeded attempt to open /usr/lib/crti.o succeeded attempt to open /tools/lib/gcc/i686-pc-linux-gnu/3.4.2/crtbegin.o succeeded attempt to open /tmp/ccSZTA2z.o succeeded attempt to open /tools/lib/gcc/i686-pc-linux-gnu/3.4.2/libgcc.a succeeded

Note that we're now linking against /usr/lib/crt1.o, /usr/lib/crti.o instead of the copies in /tools/lib. We must still link against the crtbegin.o and libgcc.a in /tools, because these files are provided by gcc and have not been installed to /usr at this particular point. Once GCC is installed, our modified specs file will be overwritten, and all will be right with the world.