http://bugs.linuxfromscratch.org/show_bug.cgi?id=1675
Summary: Ch. 6 glibc test-installation.pl tests /tools glibc
Product: Linux From Scratch
Version: SVN
Platform: PC
URL: http://linuxfromscratch.org/pipermail/lfs-dev/2006-
January/054963.html
OS/Version: All
Status: UNCONFIRMED
Severity: normal
Priority: P5
Component: Book
AssignedTo: [email protected]
ReportedBy: [EMAIL PROTECTED]
QAContact: [email protected]
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.
------- 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.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-book
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
