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
Received on Fri Jan 7 10:10:54 2011