Discussion:
[rust-dev] [ANN] Rust ported to DragonFlyBSD
Michael Neumann
2014-07-29 12:59:14 UTC
Permalink
Hi all,

I am happy to announce that I succeeded in porting Rust to the DragonFly
operating system. [This article][1] describes `how` and might also be of
interest to others porting Rust to NetBSD or OpenBSD. Within the next
week I submit patches to the LLVM project (segmented stack support for
DragonFly) and also to the rust repo itself. My `dragonfly` branch of
the Rust repository can be found [here][2].

If someone is interested to try out early, I can provide some binaries
until I set up some automatic builds.

Regards,

Michael

[1]: http://www.ntecs.de/blog/2014/07/29/rust-ported-to-dragonflybsd/
[2]: https://github.com/mneumann/rust/tree/dragonfly
Markus Pfeiffer
2014-07-29 13:07:58 UTC
Permalink
Hi Michael,

great work, and thanks for doing this!

*goes off to prod around rust*

Markus

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140729/c41ca09e/attachment.sig>
Rob Latham
2014-07-29 18:37:12 UTC
Permalink
"After trying to cross-compile Rust by specifying --target
x86_64-pc-dragonfly-elf to Rust?s own configure script and spending
numerous hours just to note that the build fails"...

Howdy, fellow crazy cross-compiling person. Did you by any chance
come across my message from a week or so ago? One response seemed
likely to help you if you were encountering a specific kind of build
failure:

https://mail.mozilla.org/pipermail/rust-dev/2014-July/010827.html

what other errors were you encountering with the --target approach?

==rob
Post by Michael Neumann
Hi all,
I am happy to announce that I succeeded in porting Rust to the DragonFly
operating system. [This article][1] describes `how` and might also be of
interest to others porting Rust to NetBSD or OpenBSD. Within the next
week I submit patches to the LLVM project (segmented stack support for
DragonFly) and also to the rust repo itself. My `dragonfly` branch of
the Rust repository can be found [here][2].
If someone is interested to try out early, I can provide some binaries
until I set up some automatic builds.
Regards,
Michael
[1]: http://www.ntecs.de/blog/2014/07/29/rust-ported-to-dragonflybsd/
[2]: https://github.com/mneumann/rust/tree/dragonfly
_______________________________________________
Rust-dev mailing list
Rust-dev at mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Michael Neumann
2014-07-30 13:44:18 UTC
Permalink
Post by Rob Latham
"After trying to cross-compile Rust by specifying --target
x86_64-pc-dragonfly-elf to Rust?s own configure script and spending
numerous hours just to note that the build fails"...
Howdy, fellow crazy cross-compiling person. Did you by any chance
come across my message from a week or so ago? One response seemed
likely to help you if you were encountering a specific kind of build
https://mail.mozilla.org/pipermail/rust-dev/2014-July/010827.html
what other errors were you encountering with the --target approach?
When building the related C libraries you also need to specify the
--sysroot to point to the DragonFly tree, otherwise it's building the
libraries targeted at DragonFly but with Linux header files, which
clearly is *wrong*. Actually I wasn't able to cross-compile LLVM. Also
when using the --target approach, I always had to wait for hours until
it finished the Linux (host) build before it started to build the
target. I think I was just waiting too much time for compiles to finish.
If someone else figures out how to cross-compile to DragonFly with the
--target approach I am happy to know :).

Regards,

Michael
Rob Latham
2014-07-30 14:04:04 UTC
Permalink
Post by Michael Neumann
Post by Rob Latham
what other errors were you encountering with the --target approach?
When building the related C libraries you also need to specify the
--sysroot to point to the DragonFly tree, otherwise it's building the
libraries targeted at DragonFly but with Linux header files, which
clearly is *wrong*.
I'd set this up in mk/platform.mk. Check out how arm-apple-ios does it:

CFG_IOS_SDK = $(shell xcrun --show-sdk-path -sdk iphoneos 2>/dev/null)
CFG_IOS_FLAGS = -target armv7-apple-darwin -isysroot $(CFG_IOS_SDK)
-mios-version-min=7.0
CFG_CFLAGS_arm-apple-ios := -arch armv7 -mfpu=vfp3 $(CFG_IOS_FLAGS)

https://github.com/rust-lang/rust/blob/master/mk/platform.mk#L158
Post by Michael Neumann
Actually I wasn't able to cross-compile LLVM. Also
when using the --target approach, I always had to wait for hours until
it finished the Linux (host) build before it started to build the
target. I think I was just waiting too much time for compiles to finish.
If someone else figures out how to cross-compile to DragonFly with the
--target approach I am happy to know :).
I agree it takes a while. ccache is a big help but it still takes a while.

==rob
Michael Neumann
2014-07-30 14:22:34 UTC
Permalink
Post by Rob Latham
Post by Michael Neumann
Post by Rob Latham
what other errors were you encountering with the --target approach?
When building the related C libraries you also need to specify the
--sysroot to point to the DragonFly tree, otherwise it's building the
libraries targeted at DragonFly but with Linux header files, which
clearly is *wrong*.
CFG_IOS_SDK = $(shell xcrun --show-sdk-path -sdk iphoneos 2>/dev/null)
CFG_IOS_FLAGS = -target armv7-apple-darwin -isysroot $(CFG_IOS_SDK)
-mios-version-min=7.0
CFG_CFLAGS_arm-apple-ios := -arch armv7 -mfpu=vfp3 $(CFG_IOS_FLAGS)
https://github.com/rust-lang/rust/blob/master/mk/platform.mk#L158
I tried this as you can see here [1]. But you have to consider that Mac
OS X comes with an iphone SDK while Linux does not come with DragonFly
"SDK" :D. I think no-one ever tried to cross-compile a program for
DragonFly :).

[1]:
https://github.com/mneumann/rust/commit/ab1124980f97558af87b789a1c0772bfa7e23704


Regards,

Michael
Valerii Hiora
2014-07-30 14:58:16 UTC
Permalink
Hi,
Also when using the --target approach, I always had to wait for hours
until it finished the Linux (host) build before it started to build
the target.
Yep, `--target` approach can be extremely exhausting. One pretty
useful dirty trick in this case is to build it once for host and play a
lot with `touch -r`. It might be used to recompile only for target when
you have changes in mk/* or src/lib*. For example, if you've changed
src/libstd/somefile.rs, you can later on do:

`touch -r src/libstd/lib.rs src/libstd/somefile.rs`

If libstd was compiled successfully before it is required also to
delete stamp:

`rm build_dir/host_triple/stage2/lib/rustlib/target_triple/lib/stamp.std`

and `make -j4` it again, just for target, no waiting for host :-)

Used it a lot while porting for iOS and while this message is
definitely late for Dragonfly - I hope it will be useful for others who
might be interested in porting to platforms which are easier accessible
through `--target` approach.
--
Valerii

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140730/b952f2e0/attachment.sig>
Loading...