Glibc sanity check

[Jeremy Huntwork]

From Tcl developer Don Porter: "at the end of the "Adjusting the Toolchain" section,

​http://www.linuxfromscratch.org/lfs/view/stable/chapter05/adjusting.html

a simple test is provided to check whether the toolchain adjustment was completed successfully. Would it be possible to enhance that test so that the ability to link against glibc and run programs using glibc is also tested?

A test and failure at that point would help LFS users get on the right track earlier, and would spare the Tcl developers getting sent these bogus bug reports."

[Matthew Burgess]

What constitutes a 'good enough' program here? I'm thinking of the following textbook "Hello World":

#include <stdio.h> int main() { printf("Hello, World!\n"); return 0; }

Now, if we do the following: ./a.out readelf -l a.out | grep ': /lib' readelf -s a.out | grep 'GLIBC' ldd a.out

the output should convince us (and our readers) that we've linked to the correct libc, and can run the resultant binaries. I'm not sure the second `readelf' is really required, I was just using it to ensure that we really were using glibc's printf, and not a compiler builtin. ​http://gcc.gnu.org/onlinedocs/gcc-3.4.4/gcc/Other-Builtins.html#Other-Builtins suggests that the builtin 'printf' will be used, unless the '-fno-builtin' option is used. However, the output of the commands above don't appear to change when the option is used/omitted. So, either those commands aren't showing me what I think they're showing me, or the GCC documentation is wrong (or I could have misinterpreted it of course!).

Can someone save me from this madness please and tell me how we can easily detect whether or not any functions in glibc will be called, and then which libc will be used once the program is executed?

[Matthew Burgess]

OK, after running the resultant program through gdb, it's pretty clear that the binary really is going to call into libc. If one compares the program in comment 1 with one which calls builtin_printf instead, the difference is pretty clear.

[Matthew Burgess]

OK, slight correction! Apparently gcc-4.0.1 gets this right:

$ gcc -Wall -Wextra dummy.c $ readelf -s a.out | grep GLIBC

1: 00000000 428 FUNC GLOBAL DEFAULT UND puts@GLIBC_2.0 (2) 2: 00000000 334 FUNC GLOBAL DEFAULT UND libc_start_main@GLIBC_2.0 (2)

66: 00000000 428 FUNC GLOBAL DEFAULT UND puts@@GLIBC_2.0 73: 00000000 334 FUNC GLOBAL DEFAULT UND libc_start_main@@GLIBC_

$ gcc -Wall -Wextra -fno-builtin dummy.c $ readelf -s a.out | grep GLIBC

1: 00000000 334 FUNC GLOBAL DEFAULT UND libc_start_main@GLIBC_2.0 (2) 2: 00000000 57 FUNC GLOBAL DEFAULT UND printf@GLIBC_2.0 (2)

72: 00000000 334 FUNC GLOBAL DEFAULT UND libc_start_main@@GLIBC_ 75: 00000000 57 FUNC GLOBAL DEFAULT UND printf@@GLIBC_2.0

[archaic@…]

HLFS has a sanity check. Granted it isn't applicable verbatim, but might give you more ideas.

​http://www.linuxfromscratch.org/hlfs/view/unstable/glibc/chapter05/gcc.html#testing-gcc

[Matthew Burgess]

Jeremy, I know you were going to take a look at this, but I just did a quick search of the TCL mailing lists myself to see what is going on. ​https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1175161&group_id=10894 and ​https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1195139&group_id=10894 seem the likliest triggers of these. Both appear to be due to the reporters not having followed LFS procedures properly (my build logs don't show compat/strstr.c being built at all). I therefore don't think anything needs to be done with the toolchain test, as it appears these folks aren't following the book properly (and therefore in all likelihood didn't bother with the toolchain test at all).

I don't think there's anything more we can do, other than politely request that the TCL folks point LFS users back to lfs-support.

[Jeremy Huntwork]

Sounds good to me. I've never seen this issue myself, either.

[alexander@…]

I have seen the strstr.c issue myself when deviating. That was an attempt to add sysroot to cross-LFS instructions. TCL somehow didn't detect that gcc was a cross-compiler. But it was obviously my error.

So I propose to add the following text after the current toolchain test:

Building TCL in the next section will also serve as an additional check that your toolchain has been built properly. If TCL fails to build, something is very wrong with your Binutils, GCC, or Glibc, but not with TCL.