On Thursday July 5 2007 05:27:51 am you wrote: > Forget my earlier posts today, my brain wasn't yet switched on :) > > > libdl.a is needed for Binutils tests, and libc.a is needed for GCC's > > tests. So, they should be moved later. I changed the book just now. > > Brilliant, i've svn-ed the latest book, make-d it, read it, used it. > Book version is now: SVN-20070705. > Retraced my steps, moved back libc.a, libdl.a, rebuilt glibc and gcc. > And sure enough: it works this time. > At least, i have now succesfully built the butterfly toolchain. > > The glibc tests still fail as do the gcc tests (fair enough there's a blurb > in the 6.12 about 'the tests will be bad').
The GCC tests should pass normally if the right -fno options are used for 'make check'. In past experiences the test suite failures were test suite bugs, not problems with gcc or binutils programs. For example, Binutils makes assumptions and if the NOW or RELRO markings are added then the test fails because extra markings were not expected. > Should they complete without errors ? The book at least mentions that the > glibc tests can return one error in 'posix/annexc'. But my make -k check > returns a bunch of them and then stops (see earlier post). The Glibc tests depend a lot on your host system kernel. The sysv driver, for example, is needed for Glibc's tests. I don't have a list of all the needed drivers yet. The only kernel I know of which will allow all the Glibc tests to pass is the Slackware kernel. > And I guess the tcl/dejagnu/expect packages are built for the gcc/binutils > tests with a reason. > > > Two things I noticed in '6.12. Butterfly Toolchain': > > echo | cc -dM -E - | grep -E 'PIC|SSP|FORTIFY|OPTIMIZE' > doesn't list '#define __OPTIMIZE__ 1' > Not sure if this will be a problem as the fgets-overflow.c and > strcpy-overflow.c tests show the expected output. Yes, __OPTIMIZE__ isn't getting defined anymore. I want to remove that check because it doesn't seem to make a difference. The test programs are more important. > And: > "The next commands demonstrates that without any protection this program > can run a buffer overflow silently, without any warnings, errors, or > crashes:" > > ehm: > #gcc -o fgets-overflow fgets-overflow.c \ > -fno-stack-protector -U_FORTIFY_SOURCE -Wall -Wformat=2 > # echo abcdefghijklm | ./fgets-overflow 14 > abcdefghijklm > Segmentation fault > I wouldn't call that exactly "silently, without crashes". Glibc and libssp don't behave the same way. Their output is different, and might be complicated by different versions. robert
pgp7k56zIoYa8.pgp
Description: PGP signature
-- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
