Closed Bug 1248391 Opened 8 years ago Closed 8 years ago

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

Categories

(Firefox Build System :: General, defect)

Unspecified
FreeBSD
defect
Not set
normal

Tracking

(firefox47 fixed, firefox48 fixed)

RESOLVED FIXED
mozilla48
Tracking Status
firefox47 --- fixed
firefox48 --- fixed

People

(Reporter: jbeich, Unassigned)

References

Details

Attachments

(2 files)

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
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
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"',
We're going to require rustc at some point, so this might as well get fixed.
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)
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!
(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.
(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 ?
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.
(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.
(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.
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.
(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 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/
Attachment #8734380 - Flags: feedback?(landry)
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 :)
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 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/
Attachment #8734380 - Attachment description: MozReview Request: Bug 1248391 - Don't pass rust --target for native builds. r?ted → MozReview Request: Bug 1248391 - Don't force rust --target on unknown platforms. r?ted
Attachment #8734380 - Flags: feedback?(landry)
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?
Attachment #8734380 - Flags: feedback?(nfroyd)
Attachment #8734380 - Flags: feedback?(landry)
Ah... now i think i see better. Cant test it right now, sadly... but that should work i think
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 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/
Attachment #8734380 - Flags: feedback?(nfroyd)
Attachment #8734380 - Flags: feedback?(landry)
(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 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.
Attachment #8734142 - Flags: review?(ted) → review+
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
Attachment #8734380 - Flags: review?(ted) → review+
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.
Maybe he meant bug 1260622. But either way, that amd64 match is dubious: config.sub old or new version canonicalize it as x86_64.
Oh, sorry, I did mean that bug but I forgot that the $target in m4 is still directly from config.guess/config.sub.
(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?
(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 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/
Attachment #8734142 - Attachment description: MozReview Request: Bug 1248391 - Unbreak --enable-rust on BSDs after bug 1177599. r?ted → MozReview Request: Bug 1248391 - Unbreak --enable-rust on BSDs after bug 1177599. r=ted
Attachment #8734380 - Attachment description: MozReview Request: Bug 1248391 - Don't force rust --target on unknown platforms. r?ted → MozReview Request: Bug 1248391 - Don't force rust --target on unknown platforms. r=ted
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/
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
Keywords: checkin-needed
(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 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
Attachment #8734142 - Flags: approval-mozilla-aurora?
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+
Attachment #8734142 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
(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 ?
Component: Build Config → General
Product: Firefox → Firefox Build System
Target Milestone: Firefox 48 → mozilla48
You need to log in before you can comment on or make changes to this bug.