Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cross compilation on *BSD #287

Closed
Ianleeclark opened this issue Aug 27, 2016 · 9 comments
Closed

Cross compilation on *BSD #287

Ianleeclark opened this issue Aug 27, 2016 · 9 comments

Comments

@Ianleeclark
Copy link

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.

@briansmith
Copy link
Owner

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.

@Ianleeclark
Copy link
Author

@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.

@briansmith
Copy link
Owner

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!

@Ianleeclark
Copy link
Author

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:

  • explicitly creating a list of targets which will ought to build with only a triple
  • 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)
  • or just adding support for FreeBSD at the moment because I can build it and leaving a note in the building README.

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

@briansmith
Copy link
Owner

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?

@alicemaz
Copy link

alicemaz commented Aug 28, 2016

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.

@Ianleeclark
Copy link
Author

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.

tatsuya6502 added a commit to tatsuya6502/ring that referenced this issue Oct 12, 2016
- build.rs
  * Default to `gmake` on BSD systems
  * Support `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.

I agree to license my contributions to each file under the terms given
at the top of each file I changed.
@tatsuya6502
Copy link
Contributor

tatsuya6502 commented Oct 15, 2016

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?)

#287 (comment)

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.

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.

@briansmith
Copy link
Owner

I think this is fixed since #313 landed? If not, let me know what's missing and I'll reopen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants