Gordan Bobic wrote: > Hi, > > I'm playing with Vserver on ARM at the moment. The kernel builds fine, > but the userspace utils are not as easy to get working. > > The big problem is dietlibc. This doesn't seem to build pass all of it's > built-in self-tests even on x86, let along anything else. With some > fixing up (see here: > https://bugzilla.redhat.com/show_bug.cgi?id=667852 ) it can be persuaded > to build, but most self-tests fail with segfaults after that (without > the patches, the diet binary itself would sefgault - it seems to be > related to gcc's optimizer being dangerously broken on ARM, at least > when handling assemblies. > > Next, it would appear that diet binary doesn't work quite as expected. > ./configure decides to run it with -Os, but this breaks things and > causes it to pass -meabi=4 to cc1, which promptly exits complaining that > it doesn't understand that parameter. Indeed, according to the man page, > -meabi doesn't take parameters. Solution for this seems to be to pass > > DIETFLAGS='' > > to ./configure. > > However, the build then proceeds to fail with the following: > > diet gcc -O2 -g -march=armv5te -std=c99 -Wall -pedantic -W > -funit-at-a-time -o src/filetime src/filetime.o lib/libvserver.a > src/filetime.o: In function `main': > /root/rpmbuild/BUILD/util-vserver-0.30.216-pre2914/src/filetime.c:74: > undefined reference to `time' > collect2: ld returned 1 exit status > make[2]: *** [src/filetime] Error 1 > make[2]: Leaving directory > `/usr/src/redhat/BUILD/util-vserver-0.30.216-pre2914' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory > `/usr/src/redhat/BUILD/util-vserver-0.30.216-pre2914' > make: *** [all] Error 2 > error: Bad exit status from /var/tmp/rpm-tmp.3pJrqV (%build) > > > RPM build errors: > Bad exit status from /var/tmp/rpm-tmp.3pJrqV (%build) > > Am I missing a library/header somewhere? Or is this just dietlibc being > broken? > > The same src.rpm package builds OK when "--without dietlibc" > (--disable-dietlibc to ./configure) is passed, but fails the hash > self-test: > > sha512 mismatch at rand-4096: > '312002a970b8949dcee2cd4c275d1f371eaba001bc313940e6a5c64630653624a56b963e3736ba1b7f7a18bb637f7e9280acd1c8487a5ca8483ed835ffbd57ff' > vs. > 'f3508428e93872dc0b8696b38d3d1e80209158889339fd081a6cc925849a9bb80a7559440bd6f7a98839e0c89428d6edc9ea64f79a7ecd0facd968e1036a5efd' > > FAIL: src/testsuite/hashcalc-plain.sh > sha512 mismatch at rand-4096: > 'ddeb4cd9598d226b1e9ee458aa285cda8d0c8e48d3db44bcdc64021f1ddb393bb9d0cd06ab49fed4f2f9c8e6432d19' > vs. > 'ef35ec379494577311c130e7139c720415e402c05f7ed4b713f3e8450556cd22014750d30dc9f0afa098820bb4fd957a48e674ba2d00185300c6b7607da2c456' > > FAIL: src/testsuite/hashcalc.sh > > This appears to happen with both the beecrupt and nss libraries being > used. Any thoughts on how to fix this? Will hashify still work with > --with-crypto-api=none? Or is that unrelated? Well, I just tried building it --with-crypto-api=none, and that compiles out the vhashify feature completely. Can it _really_ be that SHA512 is broken in both beecrypt and nss on ARM? Gordan