Fix issue #287, #311 - Support building on *BSD

[tatsuya6502]

• build.rs
  • Default to gmake on BSD systems
  • Support optional MAKE variable for pointing to correct make
• mk/top_of_makefile.mk
  • Allow target triple on *BSD not to have abi (e.g. x86_64-unknown-freebsd)
• BUILDING.md
  • Add descriptions about MAKE variable.

This is take 2 of PR #290 created by @GrappigPanda, and will address the build issue on *BSD systems:

• Cross compilation on *BSD #287
• FreeBSD compilation error #311

Tested on FreeBSD 10.3-RELEASE (amd64) using cargo test.

@briansmith @oherrala Can you please review?

[tatsuya6502]

Test Log

• FreeBSD 10.3-RELEASE-p7 (amd64)
• rustc 1.12.0 stable
• clang 3.4.1 (one that comes with FreeBSD 10.x base system)

% uname -a
FreeBSD minibsd.home.lan 10.3-RELEASE-p7 FreeBSD 10.3-RELEASE-p7 #0: Thu Aug 11 18:38:15 UTC 2016
[email protected]:/usr/obj/usr/src/sys/GENERIC  amd64
% rustc --version
rustc 1.12.0 (3191fbae9 2016-09-23)
% clang --version
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
Target: x86_64-unknown-freebsd10.3
Thread model: posix
% cargo clean
% cargo test
   Compiling untrusted v0.3.1
   Compiling ring v0.5.0 (file:///usr/home/tatsuya/workhub/dev/ring)
   Compiling lazy_static v0.2.1
    Finished debug [unoptimized + debuginfo] target(s) in 8.74 secs
     Running target/debug/deps/ring-7005a56f2c83e624

running 85 tests
test aead::chacha20_poly1305::tests::test_poly1305_state_len ... ok
test c::test_i16_metrics ... ok
test c::test_i32_metrics ... ok

...(snip)...

test aead::chacha20_poly1305::tests::chacha20_tests ... ok
test digest::tests::shavs::SHA1::monte_carlo_test ... ok

test result: ok. 85 passed; 0 failed; 0 ignored; 0 measured

   Doc-tests ring

running 13 tests
test hkdf::extract_and_expand_0 ... ok
test error::Unspecified_0 ... ok
test hmac_0 ... ok
test hmac_1 ... ok
test agreement_0 ... ok
test test_0 ... ignored
test digest::Context_0 ... ok
test digest::digest_0 ... ok
test hmac_2 ... ok
test signature::verify_0 ... ok
test signature_1 ... ok
test signature_0 ... ok
test pbkdf2_0 ... ok

test result: ok. 12 passed; 0 failed; 1 ignored; 0 measured

[coveralls]

Coverage remained the same at 91.126% when pulling 4102ae7 on tatsuya6502:bsd-support into 5a2c0a2 on briansmith:master.

[briansmith]

Thanks a lot! I don't have a BSD system handy so I'll take your word for it that this fixes the build. And thanks to @tymat for testing it.

If you are interested in better BSD support, one obvious next step would be to replace the implementation of ring::rand with one that uses arc4random or whatever is best on BSD, instead of using reads from /dev/urandom.

[tatsuya6502]

@briansmith Thanks for merging.

If you are interested in better BSD support, one obvious next step would be to replace the implementation of ring::rand with one that uses arc4random or whatever is best on BSD, instead of using reads from /dev/urandom.

OK. Let me work on that. I did a bit of research and arc4random seems the best on BSD by the following reasons:

• It is widely available on BSD systems.
• It produces high quality data.
• It is non blocking.

http://man.openbsd.org/OpenBSD-6.0/arc4random.3

This family of functions provides higher quality data than those described in rand(3), random(3), and rand48(3).

Use of these functions is encouraged for almost all random number consumption because the other interfaces are deficient in either quality, portability, standardization, or availability. These functions can be called in almost all coding environments, including pthreads(3) and chroot(2).

[briansmith]

OK. Let me work on that.

Great. I filed a new issue #316 to discuss it.