1248391 - configure: error: don't know how to translate x86_64-unknown-freebsd11.0 for rustc

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Jan Beich]

Bug 1177599 broke --enable-rust on Tier3 platforms like BSDs. I'm not sure about NetBSD but Bitrig, DragonFly, FreeBSD and OpenBSD are supported by Rust upstream.

  checking for rustc... /usr/local/bin/rustc
  checking rustc version... 1.6.0 (1.6.0)
  configure: error: don't know how to translate x86_64-unknown-freebsd11.0 for rustc

https://github.com/rust-lang/rust/blob/master/src/snapshots.txt

Comment 1

[Alex Crichton [:acrichto]]

Ah, so to clarify from the Rust side, all of these BSDs are "Tier 3" support for us which means [1] that the platforms are not guaranteed to either build or pass tests. These platforms in practice rarely complete a bootstrap because they bitrot quickly (we have no automation we gate on), and it's a community effort to send patches to get the build working again for them.

Along those lines, while it's still possible, I'd probably recommend disabling Rust for these platforms in the near future. If Gecko *requires* Rust to be enabled at some point, however, we can look into promoting these to at least Tier 2 platforms for us which means we at least guarantee they build (with a "high likelihood" that the tests pass).

Additionally, the Rust compiler currently doesn't understand targets with numbers at the end, so for us at least the only target we recognize is x86_64-unknown-freebsd, not x86_64-unknown-freebsd11.0

Hope that helps!

[1]: http://doc.rust-lang.org/book/getting-started.html#tier-3

Comment 2

[Jan Beich]

Linux Desktop already ships with --enable-rust per bug 1243363. It seems Gecko plans to accelerate --disable-rust deprecation.

https://www.mail-archive.com/dev-platform%40lists.mozilla.org/msg17614.html

  $ tail -1 build/mozconfig.rust
  ac_add_options --enable-rust

  $ fgrep -r mozconfig.rust browser/config
  browser/config/mozconfigs/macosx-universal/beta:. "$topsrcdir/build/mozconfig.rust"
  browser/config/mozconfigs/macosx-universal/release:. "$topsrcdir/build/mozconfig.rust"
  browser/config/mozconfigs/macosx-universal/nightly:. "$topsrcdir/build/mozconfig.rust"
  browser/config/mozconfigs/win64/debug:. "$topsrcdir/build/mozconfig.rust"
  browser/config/mozconfigs/win64/nightly:. "$topsrcdir/build/mozconfig.rust"
  browser/config/mozconfigs/win32/debug:. "$topsrcdir/build/mozconfig.rust"
  browser/config/mozconfigs/win32/debug-static-analysis:. "$topsrcdir/build/mozconfig.rust"
  browser/config/mozconfigs/linux64/beta:. "$topsrcdir/build/mozconfig.rust"
  browser/config/mozconfigs/linux64/debug:. "$topsrcdir/build/mozconfig.rust"
  browser/config/mozconfigs/linux64/nightly:. "$topsrcdir/build/mozconfig.rust"
  browser/config/mozconfigs/linux64/release:. "$topsrcdir/build/mozconfig.rust"
  browser/config/mozconfigs/macosx64/opt-static-analysis:. "$topsrcdir/build/mozconfig.rust"
  browser/config/mozconfigs/macosx64/debug:. "$topsrcdir/build/mozconfig.rust"
  browser/config/mozconfigs/macosx64/nightly:. "$topsrcdir/build/mozconfig.rust"
  browser/config/mozconfigs/whitelist:    '. "$topsrcdir/build/mozconfig.rust"',

Comment 3

[(not currently active) Ted Mielczarek]

We're going to require rustc at some point, so this might as well get fixed.

Comment 4

[Jan Beich]

Attachment: MozReview Request: Bug 1248391 - Unbreak --enable-rust on BSDs after bug 1177599. r=ted

Review commit: https://reviewboard.mozilla.org/r/42105/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/42105/

Comment 5

[Jan Beich]

Currently, downstream rust package (on BSDs) is regularly updated only on FreeBSD and OpenBSD. No runtime issues on FreeBSD 11.0C amd64 with rust 1.7.0 like before bug 1177599. Chasing bug 1243363 via an option in www/firefox port is on my TODO.

Example $target values below. uname -p may return amd64 on FreeBSD and OpenBSD. GNU/kFreeBSD is mostly a guess assuming Rust ignores libc and goes straight for syscalls.

- x86_64-unknown-dragonfly4.5

- x86_64-unknown-freebsd11.0
- amd64-portbld-freebsd11.0 (ports)
- x86_64-unknown-kfreebsd11.0-gnu (Debian)

- x86_64-unknown-netbsd7.99.24

- amd64-unknown-openbsd5.7
- x86_64-unknown-openbsd5.7 (after config.sub)

Comment 6

[Landry Breuil (:gaston)]

We dont have bootstraps yet, but we're also targeting i386-unknown-openbsdX.Y, even if it's a lost cause on the long term.. if that case can be handled too, that'd be nice.

The discussion on m.d.p about always requiring a very latest/recent version of rustc is worsening me though...

Thanks jan for your work on this!

Comment 7

[Martin Husemann]

(In reply to Ted Mielczarek [:ted.mielczarek] from comment #3)
> We're going to require rustc at some point, so this might as well get fixed.

This is very sad from a portability point of view.

Comment 8

[Landry Breuil (:gaston)]

(In reply to Martin Husemann from comment #7)
> (In reply to Ted Mielczarek [:ted.mielczarek] from comment #3)
> > We're going to require rustc at some point, so this might as well get fixed.
> 
> This is very sad from a portability point of view.

Agreed, but that ship has sailed a long while ago unfortunately. Powerpc and sparc have been struggling since 3+ years now :) see the last posts on http://tenfourfox.blogspot.fr/ at least....

Having rust as a build dependency was just obviously coming to the party. But you have rust on NetBSD/amd64 at least, right ?

Comment 9

[Martin Husemann]

I am a compiler guy (originally), so I'll have a look at rust for sparc64 (sounds like fun; next stop: go). Happy that it is optional for now.

Comment 10

[Jan Beich]

(In reply to Landry Breuil (:gaston) from comment #6)
> We dont have bootstraps yet, but we're also targeting i386-unknown-openbsdX.Y,
> even if it's a lost cause on the long term.. if that case can be handled too,
> that'd be nice.

What value for rust_target=? i686-unknown-openbsd, i586-unknown-openbsd, i386-unknown-openbsd ? And while your sentence is written in present tense I don't see i386 support either upstream or in OpenBSD ports. If we're talking about *future* then FreeBSD and NetBSD may want to go beyond x86.

Bug 1177599 improved cross-compiling and fat binary builds at the cost of native builds on new or less supported platforms e.g., aarch64*linux-android or arm*linux-gnu. Maybe we should conditionalize --target=${rust_target} like it was before.

(In reply to Ted Mielczarek [:ted.mielczarek] from Bug 1177599 comment #0)
> ... want to check in configure that the rustc we find can generate code for the target architecture.

How Rust is different from Clang in this case? Both can target more than one platform, so it doesn't matter much for which platform they were built as long as libs for target are around. Besides, -m32 or foreign ABI binaries on Unix-like systems (except OS X, Android) are usually prefixed to differentiate with native ones or installed somewhere outside of PATH to avoid conflict.

Comment 11

[Landry Breuil (:gaston)]

(In reply to Jan Beich from comment #10)
> (In reply to Landry Breuil (:gaston) from comment #6)
> > We dont have bootstraps yet, but we're also targeting i386-unknown-openbsdX.Y,
> > even if it's a lost cause on the long term.. if that case can be handled too,
> > that'd be nice.
> 
> What value for rust_target=? i686-unknown-openbsd, i586-unknown-openbsd,
> i386-unknown-openbsd ? And while your sentence is written in present tense I
> don't see i386 support either upstream or in OpenBSD ports. If we're talking
> about *future* then FreeBSD and NetBSD may want to go beyond x86.

Yes, when i said 'we dont have bootstraps' that means 'support is inexistent as of now' upstream and in our ports. But that's in the pipe. As for the value, guess i686-unknown-openbsd like you're doing for freebsd will do.

Comment 12

[Martin Husemann]

We don't either currently, the pkgsrc folks are waiting for the Rust 1.8 release. Apparently the bitrig folks did some nice python hack to avoid binary bootstraps.

Tuple should be i386-unknown-netbsd and amd64-unknown-netbsd I guess.

Comment 13

[Jan Beich]

(In reply to Martin Husemann from comment #12)
> Tuple should be i386-unknown-netbsd and amd64-unknown-netbsd I guess.

amd64 already exists upstream as x86_64. Besides, config.guess uses hw.machine_arch which returns x86_64 (like uname -p) and even if you pass amd64 target as argument config.sub will convert it to x86_64.

  $ build/autoconf/config.sub amd64-unknown-netbsd
  x86_64-unknown-netbsd

https://github.com/rust-lang/rust/tree/master/mk/cfg

Comment 14

[Jan Beich]

Comment on attachment 8734142 [details]
MozReview Request: Bug 1248391 - Unbreak --enable-rust on BSDs after bug 1177599. r=ted

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/42105/diff/1-2/

Comment 15

[Jan Beich]

Attachment: MozReview Request: Bug 1248391 - Don't force rust --target on unknown platforms. r=ted

Review commit: https://reviewboard.mozilla.org/r/42189/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/42189/

Comment 16

[Landry Breuil (:gaston)]

Comment on attachment 8734380 [details]
MozReview Request: Bug 1248391 - Don't force rust --target on unknown platforms. r=ted

Sorry, but i have no idea what that does/means :)

Comment 17

[Nathan Froyd [:froydnj]]

https://reviewboard.mozilla.org/r/42189/#review38761

::: build/autoconf/rust.m4:36
(Diff revision 1)
>        version 1.5 of the 'rustc' toolchain and make sure it is
>        first in your path.
>        You can verify this by typing 'rustc --version'.])
>    fi
>  
> -  if test -n "$RUSTC" -a -n "$MOZ_RUST"; then
> +  if test -n "$RUSTC" -a -n "$MOZ_RUST" -a -n "$CROSS_COMPILE"; then

Even in the non-cross-compile case, I think we want to ensure Rust is receiving the right target triple (e.g. the MSVC triple on Windows or--forthcoming--the non-SSE triples on our x86 platforms).

Comment 18

[Jan Beich]

Comment on attachment 8734380 [details]
MozReview Request: Bug 1248391 - Don't force rust --target on unknown platforms. r=ted

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/42189/diff/1-2/

Comment 19

[Jan Beich]

Comment on attachment 8734380 [details]
MozReview Request: Bug 1248391 - Don't force rust --target on unknown platforms. r=ted

Landry, does this work as an alternative to (prematurely) adding i686-unknown-openbsd?

Comment 20

[Landry Breuil (:gaston)]

Ah... now i think i see better. Cant test it right now, sadly... but that should work i think

Comment 21

[Jan Beich]

https://reviewboard.mozilla.org/r/42189/#review38785

::: build/autoconf/rust.m4:117
(Diff revision 2)
>        x86_64-pc-mingw32)
>            # XXX and here as well
>            rust_target=x86_64-pc-windows-msvc
>            ;;
>        *)
> -          AC_ERROR([don't know how to translate $target for rustc])
> +          # Fall back to implicit (native) target on unknown platforms

Oops, AC_ERROR() must remain for CROSS_COMPILE case or it'd be asking for broken build later.

Comment 22

[Jan Beich]

Comment on attachment 8734380 [details]
MozReview Request: Bug 1248391 - Don't force rust --target on unknown platforms. r=ted

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/42189/diff/2-3/

Comment 23

[(not currently active) Ted Mielczarek]

(In reply to Jan Beich from comment #10)
> How Rust is different from Clang in this case? Both can target more than one
> platform, so it doesn't matter much for which platform they were built as
> long as libs for target are around. Besides, -m32 or foreign ABI binaries on
> Unix-like systems (except OS X, Android) are usually prefixed to
> differentiate with native ones or installed somewhere outside of PATH to
> avoid conflict.

There's two parts to this with Rust:
1) Supports the target CPU architecture.
2) Has a libstd built for the target system.

If you download a prebuilt Rust package, it's likely to only have libstd for the native architecture, so if you tried to target arm-android with it it would not work.

Comment 24

[(not currently active) Ted Mielczarek]

Comment on attachment 8734142 [details]
MozReview Request: Bug 1248391 - Unbreak --enable-rust on BSDs after bug 1177599. r=ted

https://reviewboard.mozilla.org/r/42105/#review40121

I trust that you've got the triples correct.

::: build/autoconf/rust.m4:65
(Diff revision 2)
> +      # FreeBSD, GNU/kFreeBSD
> +      i*86-*-*freebsd*)
> +          rust_target=i686-unknown-freebsd
> +          ;;
> +      # can be amd64 due to https://svnweb.freebsd.org/changeset/ports/319948
> +      x86_64-*-*freebsd*|amd64-*-*freebsd*)

You should re-check this in light of bug 1255305.

Comment 25

[(not currently active) Ted Mielczarek]

Comment on attachment 8734380 [details]
MozReview Request: Bug 1248391 - Don't force rust --target on unknown platforms. r=ted

https://reviewboard.mozilla.org/r/42189/#review40125

Comment 26

[Jan Beich]

https://reviewboard.mozilla.org/r/42105/#review40121

|case| patterns are based on comment 5 data after running GNU config inside a VM or a jail for FreeBSD-based targets.

> You should re-check this in light of bug 1255305.

Do you mean bug 1250301 dependencies? rust.m4 haven't been converted to configure.py. It still uses $target defined by GNU config.

Comment 27

[Mike Hommey [:glandium]]

Maybe he meant bug 1260622. But either way, that amd64 match is dubious: config.sub old or new version canonicalize it as x86_64.

Comment 28

[(not currently active) Ted Mielczarek]

Oh, sorry, I did mean that bug but I forgot that the $target in m4 is still directly from config.guess/config.sub.

Comment 29

[Jan Beich]

(In reply to Mike Hommey [:glandium] from comment #27)
From my understanding, long ago FreeBSD Ports added a copy of then recent config.guess and config.sub to support newer platforms. As time went on ports started to depend on the behavior but later the upstream canonicalized amd64 as x86_64. A few years ago config.* was finally updated but x86_64 change got quickly backed out due to breakage. I've filed a bug to undo the damage

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208440

Do you want me to remove |amd64-*-*freebsd*| from case pattern build/autoconf/rust.m4?

Comment 30

[Mike Hommey [:glandium]]

(In reply to Jan Beich from comment #29)
> Do you want me to remove |amd64-*-*freebsd*| from case pattern
> build/autoconf/rust.m4?

I guess the question is when you build firefox, are you replacing the in-tree config.sub? If not, then the amd64 case is not doing anything useful.

Comment 31

[Jan Beich]

Comment on attachment 8734142 [details]
MozReview Request: Bug 1248391 - Unbreak --enable-rust on BSDs after bug 1177599. r=ted

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/42105/diff/2-3/

Comment 32

[Jan Beich]

Comment on attachment 8734380 [details]
MozReview Request: Bug 1248391 - Don't force rust --target on unknown platforms. r=ted

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/42189/diff/3-4/

Comment 33

[Jan Beich]

Dropped amd64 case pattern while carrying over r=ted.

Mk/bsd.port.mk has the following snippet which is run by www/firefox port. To avoid issues in Mozilla tree I'm overriding amd64 back to x86_64. So, it may only affect *new* ports that end up building bundled Gecko code.

  # WRKDIR is where stuff is extracted to
  .if defined(GNU_CONFIGURE)
	  @CONFIG_GUESS_DIRS=$$(${FIND} ${WRKDIR} -name config.guess -o -name config.sub \
		  | ${XARGS} -n 1 ${DIRNAME}); \
	  for _D in $${CONFIG_GUESS_DIRS}; do \
		  ${RM} $${_D}/config.guess; \
		  ${CP} ${TEMPLATES}/config.guess $${_D}/config.guess; \
		  ${CHMOD} a+rx $${_D}/config.guess; \
		  ${RM} $${_D}/config.sub; \
		  ${CP} ${TEMPLATES}/config.sub $${_D}/config.sub; \
		  ${CHMOD} a+rx $${_D}/config.sub; \
	  done
  .endif

Comment 34

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/7511231503fb
https://hg.mozilla.org/integration/mozilla-inbound/rev/70e88ad13719

Comment 35

[Jan Beich]

(In reply to Jan Beich from comment #5)
> Chasing bug 1243363 via an option in www/firefox port is on my TODO.

Done but the impact may not be felt until the next Firefox release due to how our users have a habit to upgrade mainly chasing security fixes.
https://github.com/freebsd/freebsd-ports/commit/419562f257
https://github.com/freebsd/freebsd-ports/commit/8e63e7232e

Comment 36

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/7511231503fb
https://hg.mozilla.org/mozilla-central/rev/70e88ad13719

Comment 37

[Jan Beich]

Comment on attachment 8734142 [details]
MozReview Request: Bug 1248391 - Unbreak --enable-rust on BSDs after bug 1177599. r=ted

Mainly for smooth ride for Tier3 downstream while it starts to pass --enable-rust following upstream builds for Tier1.

Approval Request Comment
[Feature/regressing bug #]: bug 1177599 regression
[User impact if declined]: broken build with --enable-rust on FreeBSD, OpenBSD, etc.
[Describe test coverage new/current, TreeHerder]: via mozreview, m-i, m-c
[Risks and why]: Low, can only break build either due to bogus $target match or lack of --target during cross-compilation or fat binary build.
[String/UUID change made/needed]: None

Comment 38

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8734142 [details]
MozReview Request: Bug 1248391 - Unbreak --enable-rust on BSDs after bug 1177599. r=ted

We plan to enable rust on linux in 47. Aurora+

Comment 39

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/636964569c3b
https://hg.mozilla.org/releases/mozilla-aurora/rev/36ad0d4df02c

Comment 40

[Landry Breuil (:gaston)]

(In reply to Ritu Kothari (:ritu) from comment #38)

> We plan to enable rust on linux in 47. Aurora+

Will it be a hard requirement ?