Hey there.
So while attempting to cargo build a personal project depending on Ring, my PC-BSD (based on FreeBSD) system was failing to make properly. This was easily fixed by using gmake. It seems that right now, make is explicitly called whenever msbuild is not detected.
I can't imagine rust users who also use BSD are a huge group, but regardless, I imagine this can be a fairly simple fix. I'm willing to make a patch for this, but please note, I've been learning rust for all of 30 minutes.
Maybe we need to observe $MAKE in the build.rs? I would be happy to accept the PR but I can't verify it.
In general, I'm happy to accept PRs for BSD. If you know how to make Travis CI do BSD that would be great too. If you know how to adapt the getrandom stuff to BSD that would also be great. Right now it's reading from /dev/urandom.
@briansmith Sadly, Travis CI doesn't support BSD. As for /dev/urandom, I'd ask a kernel developer, but from what I remember, /dev/urandom on BSD doesn't work like it does on Linux: /dev/urandom won't have the initial point-of-weakness at initial OS install, as it blocks until it receives entropy from /dev/random. I might be off-base on this, though because I never have to deal too much with CSPRNGs.
As for the issue at hand, I was able to cargo build --release ring with only minor voodoo, so I'll try and get a patch made tomorrow for you to look at.
Thanks.
As for the issue at hand, I was able to cargo build --release ring with only minor voodoo, so I'll try and get a patch made tomorrow for you to look at.
Awesome!
Hey @briansmith Just wanted to get some clarification on this.
From looking at the targets that rustc supports, it looks like the FreeBSD doesn't require explicitly setting an ABI. I see three solutions and just want to see what you'd prefer:
Regardless, here's a list of target triples supported:
ian@ian-desktop ~/D/r/ring> rustc --print target-list
aarch64-apple-ios
aarch64-linux-android
arm-linux-androideabi
armv7-apple-ios
armv7-linux-androideabi
armv7s-apple-ios
i386-apple-ios
i686-apple-darwin
i686-linux-android
i686-unknown-dragonfly
i686-unknown-freebsd
le32-unknown-nacl
x86_64-apple-darwin
x86_64-apple-ios
x86_64-rumprun-netbsd
x86_64-sun-solaris
x86_64-unknown-bitrig
x86_64-unknown-dragonfly
x86_64-unknown-freebsd
x86_64-unknown-netbsd
x86_64-unknown-openbsd
only adding support for the BSDs (I can't really test OpenBSD/NetBSD, but it seems they are supported as target-triples and they both use the same C standard library as FreeBSD)
This seems the best to me. Or, maybe we should just invoke gmake instead of make?
As for /dev/urandom, I'd ask a kernel developer, but from what I remember, /dev/urandom on BSD doesn't work like it does on Linux: /dev/urandom won't have the initial point-of-weakness at initial OS install, as it blocks until it receives entropy from /dev/random.
The BSDs all handle this differently--on FreeBSD at least, /dev/urandom is simply a symlink to /dev/random, which blocks until it has gathered sufficient entropy and then never again.
The BSDs all handle this differently--on FreeBSD at least, /dev/urandom is simply a symlink to /dev/random, which blocks until it has gathered sufficient entropy and then never again.
ian@ian-desktop /dev> ls -al | grep urandom
lrwxr-xr-x 1 root wheel 6 Aug 28 17:14 urandom -> random
Cool, never knew that.
PR #313 has been merged, and now _ring_ can be built on BSD systems (at least on FreeBSD. I guess OpenBSD needs #294 to be resolved?)
https://github.com/briansmith/ring/issues/287#issuecomment-242895943
In general, I'm happy to accept PRs for BSD. If you know how to make Travis CI do BSD that would be great too. If you know how to adapt the
getrandomstuff to BSD that would also be great. Right now it's reading from/dev/urandom.
FYI, I will work on the above stuff.
As for Travis CI, I found libc crate is making Travis CI to do FreeBSD, NetBSD and OpenBSD. And the way they implemented them is well-documented here. They use QEMU for user-land emulation so it will be super slow but still usable if libraries are small enough to build.
As for adapting the getrandom Linux syscall to BSD, I will explore an option to use arc4random_buf() library function on BSD systems.
I think this is fixed since #313 landed? If not, let me know what's missing and I'll reopen.