Ch. 6 glibc test-installation.pl tests /tools glibc

[dbn.lists@…]

When glibc is installed without the install_root variable, a sanity check is run at the end of the installation. A simple C program is compiled that links in all the libraries of the new glibc and prints a success message "Your new glibc installation seems to be ok." if execution passes. In LFS, when glibc is built in Ch. 6, the toolchain is still pointed at /tools. Only after Ch. 6.12 Re-adjusting the Toolchain is it pointed at /.

This results in test-installation.pl testing the glibc in /tools. This usually returns as successful because the glibc's in Ch. 5 and Ch. 6 are built identically. However, it would be more accurate to alter the perl script test-installation.pl to test our new glibc. Especially since it is not necessarily the case that the two glibc's are built same. For instance, your final glibc may use the libidn add-on, but there's no reason to have it in /tools. This provides a good test case.

Here are some possible solutions:

1. Leave it as is. This isn't as stupid as it sounds since this is the way it's

always been. LFS usually builds glibc the same in Ch. 5 and Ch. 6. Also, in Re-adjusting the Toolchain, the sanity check is very similar to the one done in test-installation.pl. So, there already is a mini test-installation after we've gotten the toolchain pointed back at /.

2. Fix the test so it compiles and runs with the right libraries. This requires

two steps. First, the compiling steps must find the .so's in /usr/lib rather than /tools/lib. I'm not sure if this is because the gcc specs are pointed at /tools or the binutils linker is pointed at tools. Either way, this can be cirumvented by passing -L/usr/lib to the compiler statements. Next, when execution is performed, the gcc specs as is will force the binary to use the dynamic linker /tools/lib/ld-linux.so.2. In turn, this will dynamically link the binary to the .so's in /tools/lib. This can be circumvented by adding an RPATH to the binaries so that it looks at a different path first. This is done at compile time with -Wl,-rpath,/lib:/usr/lib. So, the whole fix for this solution is:

sed -i.bak \

's|libs -o|libs -L/usr/lib -Wl,-rpath,/lib:/usr/lib -o|' \ scripts/test-installation.pl

3. Fix the test so that it compiles with the right libraries and runs with the

right dynamic linker. This is very similar to 2. -L/usr/lib is still needed to find the right libraries at compile time. However, instead of using the dynamic linker in /tools and telling it to search a different path, we can hardcode the new dynamic linker location into the binary. This is done by adding -Wl,-dynamic-linker=/lib/ld-linux.so.2 to the compiler statements. The new dynamic linker will use the new libraries in /lib and /usr/lib by default. This is an improvement over 2 since it actually tests the new dynamic linker. The fix for this solution is:

sed -i.bak \

's|libs -o|libs -L/usr/lib -Wl,-dynamic-linker=/lib/ld-linux.so.2 -o|' \ scripts/test-installation.pl

The only drawback of this solution is that we're assuming the name of the new dynamic linker. Recently someone building on PPC said his linker was named /lib/ld.so.1. When and how this is decided I'm not sure. This is my only cause of alarm with 3.

4. Use make install_root=/ install. This overrides the test, so there will be

no false results. The drawback here is obvious since you're suppressing a nice sanity check.

[dbn.lists@…]

sed -i.bak \

's|libs -o|libs -L/usr/lib -Wl,-dynamic-linker=/lib/ld-linux.so.2 -o|' \ scripts/test-installation.pl

I forgot. This is from Greg Shafer at DIY-Linux. You can also see this here:

​http://www.diy-linux.org/x86-reference-build/chroot.html#c-glibc

[alexander@…]

I am strongly against (2), because of the wrong ELF interpreter;

(1) is OK for non-UTF8 book, and

(3) or (4) are equally good. Choose one that is easier to explain and understand.

As for the "nice sanity check", it is no longer nice because you have to adjust things for it to work properly.

[dbn.lists@…]

(In reply to comment #2)

I am strongly against (2), because of the wrong ELF interpreter;

(1) is OK for non-UTF8 book, and

I'm not sure why you think that (1) is better than (2) since (1) tests both the wrong libraries and wrong dynamic linker. To me, they're both broken. (1) is equally bad for any build. It only causes an error in the UTF8 book since you have to build libidn in /tools.

As for the "nice sanity check", it is no longer nice because you have to adjust things for it to work properly.

I suppose, but this is only because LFS is a very special case where we are using a cross-linker. In most installations, your toolchain would be pointed at the standard location and this wouldn't be an issue.

[Matthew Burgess]

Seems like 3. is the obviously correct way to go. Assuming Greg is happy taking his fix (with due credit of course) we'll do that then. Thanks for raising this one, Dan.

[dbn.lists@…]

So, everyone likes 3. I tested it on an x86 box, and it works. Now, the one thing no one has commented on is the use of /lib/ld-linux.so.2. Maybe I'm being paranoid, but the dynamic linker doesn't always go by this name. It even says in the LFS book. Should it just be assumed that if you have a different name (e.g. /lib/ld.so.1) that you can fix the sed for yourself?

I really don't want to scrap the solution for this reason, but just want everyone to be aware. If the LFS book is assuming x86 only, then this isn't a problem. I don't know what the official stance on that is, though.

[dbn.lists@…]

Umm, when I said everyone I was thinking that more than 2 people had replied. I'll probably make a patch to the book using 3, but I didn't mean to imply this was a fixed issue.

And I think Greg is alright with LFS using it since he posted the fix to the list: ​http://linuxfromscratch.org/pipermail/lfs-dev/2006-January/054963.html

[alexander@…]

I'll probably make a patch to the book using 3

The UTF-8 patch already implements (4). I have nothing real against (3), but won't redo the patch just because of that. If everyone asks me to change every little thing where the UTF-8 patch conflicts (and it conflicts pretty much everywhere) and delay the patch because of that little thing, we will never officially support UTF-8.

The patch has grown too big. I dare say that UTF-8-enabled LFS is not LFS at all.

[randy@…]

As far as LFS being x86 only, I'd say that is definately not the policy. There is at least one package where the default instructions written in the book are for PPC and you must edit this for x86.

[dbn.lists@…]

If everyone asks me to change every little thing where the UTF-8 patch conflicts (and it conflicts pretty much everywhere) and delay the patch because of that little thing, we will never officially support UTF-8.

I never said anything about changing your patch. However you implement that section, it can always be changed later. I'm just going to work on a patch to the current book to figure out the wording and such. I don't consider this a UTF-8 issue, anyway. You just happened to kick it into plain light for everyone to see.

[Jeremy Huntwork]

(In reply to comment #8)

As far as LFS being x86 only, I'd say that is definately not the policy. There is at least one package where the default instructions written in the book are for PPC and you must edit this for x86.

What? Link please. As far as I know, the LFS book is, and always has been, only for x86. There is only one spot that I'm aware of that even recognizes the possibility of another arch, and that is a note that says your linker may be different.

[randy@…]

(In reply to comment #10)

(In reply to comment #8)

As far as LFS being x86 only, I'd say that is definately not the policy. There is at least one package where the default instructions written in the book are for PPC and you must edit this for x86.

What? Link please. As far as I know, the LFS book is, and always has been, only for x86. There is only one spot that I'm aware of that even recognizes the possibility of another arch, and that is a note that says your linker may be different.

Sigh.....

I'm fairly busy. Either you or I needs to grep the LFS SVN sources for PPC or ppc or powerpc or PowerPC or some combination of those to find it.

And you seem much more interested in it than I. :-)

[dbn.lists@…]

As far as LFS being x86 only, I'd say that is definately not the policy. There is at least one package where the default instructions written in the book are for PPC and you must edit this for x86.

What? Link please. As far as I know, the LFS book is, and always has been, only for x86. There is only one spot that I'm aware of that even recognizes the possibility of another arch, and that is a note that says your linker may be different.

It's patch (-D_GNU_SOURCE) ​http://www.linuxfromscratch.org/lfs/view/development/chapter06/patch.html

Also, LFS used to be for more arches (at least PPC). If you look in the museum, I believe LFS-3 had dedicated books for x86 and PPC.

[Matthew Burgess]

It's patch (-D_GNU_SOURCE) ​http://www.linuxfromscratch.org/lfs/view/development/chapter06/patch.html

Also, LFS used to be for more arches (at least PPC). If you look in the museum, I believe LFS-3 had dedicated books for x86 and PPC.

Yep, I'm of the opinion that the "CPPFLAGS=-D_GNU_SOURCE" setting and its explanation can be removed from the book now. The cross-lfs/multi-arch books cover non-x86 architectures far more comprehensively than the core LFS book ever can, so we should just remove the note to stop sending out mixed messages about the books supported architecture(s).

[alexander@…]

The book should contain only one solution. Right now, it contains both (3) and (4).

[Jeremy Huntwork]

Solution #3 chosen.