Subject: Re: [vserver] Vserver on ARM
From: Gordan Bobic <gordan@bobich.net>
Date: Fri, 07 Jan 2011 10:10:39 +0000

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