Fixed
Status Update
No update yet.
Comments
ar...@appspot.gserviceaccount.com
ma...@google.com
Restrict bug visibility to Google internal.
ll...@google.com
we are not opposed to have the compiler binaries delivered in the tarball.
However, we cannot promise any support for those binaries unless we have a discussion about resources and funding. Unfortunately, we cannot offer you an SLA. We can opportunistically try to help with you issues but we cannot guarantee service times or anything like that. It would be up to you to find fixes or workarounds if the issue is high priority for you.
About putting the binaries in the tarball, at this point we are not sure what that entitles. If it is easy we will try to deliver it soon. If it is more involved, we may put it in the backburner. We are learning about the toolchain and there are other things that are higher priority for us ATM.
Hope this helps, and sorry we cannot offer more at the moment.
However, we cannot promise any support for those binaries unless we have a discussion about resources and funding. Unfortunately, we cannot offer you an SLA. We can opportunistically try to help with you issues but we cannot guarantee service times or anything like that. It would be up to you to find fixes or workarounds if the issue is high priority for you.
About putting the binaries in the tarball, at this point we are not sure what that entitles. If it is easy we will try to deliver it soon. If it is more involved, we may put it in the backburner. We are learning about the toolchain and there are other things that are higher priority for us ATM.
Hope this helps, and sorry we cannot offer more at the moment.
gb...@google.com
From offline discussions, the Cast folks sound okay with what Luis said in #c3.
Rephrasing, the CrOS toolchain will shuffle rustc bits (and whatever additional libraries are required to run `rustc`) into SDK tarballs. If bugs appear, we'll try to help out if we have spare cycles, but are unable to provide specific testing for these targets or SLAs at this time. In other words, the onus of validating that whatever `rustc` we happen to ship works for Cast is going to be on the Cast team.
Assuming this is OK, will try to get a better understanding of how to ship rustc+supporting libs as a part of said tarball.
Rephrasing, the CrOS toolchain will shuffle rustc bits (and whatever additional libraries are required to run `rustc`) into SDK tarballs. If bugs appear, we'll try to help out if we have spare cycles, but are unable to provide specific testing for these targets or SLAs at this time. In other words, the onus of validating that whatever `rustc` we happen to ship works for Cast is going to be on the Cast team.
Assuming this is OK, will try to get a better understanding of how to ship rustc+supporting libs as a part of said tarball.
gb...@google.com
As an update, I was able to package `rustc` as a part of our cross-compilers. I can make it produce a working binary if:
- cross-compilers are available on ${PATH}
- `--sysroot` is explicitly specified (even for host binaries)
I believe the former is because of how we configure Rust: if these compilers are already going to be on $PATH anyway (they are for SimpleChrome; dunno what Cast's setup looks like), I don't see this being a huge issue. I plan to quickly TAL to see if a small fix can be applied here, though.
`--sysroot` is slightly more awkward: `rustc` uses `/proc/self/exe` to figure out where the compiler is, whiiiiich it then uses to figure out where the sysroot is. `/proc/self/exe` always points to `${cross_compiler_tarball_root}/lib/ld-linux-x86-64.so.2` because of how it's invoked, so the sysroot is never correct. It seems best to patch the stdlib to handle this, but I'm not immediately sure what the best way to go about this is. Will continue digging on this, but the fix referenced in
I have to do other minor housekeeping things aside from these, but from a usability standpoint, those are the roadbumps I see directly in front of shipping this.
- cross-compilers are available on ${PATH}
- `--sysroot` is explicitly specified (even for host binaries)
I believe the former is because of how we configure Rust: if these compilers are already going to be on $PATH anyway (they are for SimpleChrome; dunno what Cast's setup looks like), I don't see this being a huge issue. I plan to quickly TAL to see if a small fix can be applied here, though.
`--sysroot` is slightly more awkward: `rustc` uses `/proc/self/exe` to figure out where the compiler is, whiiiiich it then uses to figure out where the sysroot is. `/proc/self/exe` always points to `${cross_compiler_tarball_root}/lib/ld-linux-x86-64.so.2` because of how it's invoked, so the sysroot is never correct. It seems best to patch the stdlib to handle this, but I'm not immediately sure what the best way to go about this is. Will continue digging on this, but the fix referenced in
I have to do other minor housekeeping things aside from these, but from a usability standpoint, those are the roadbumps I see directly in front of shipping this.
bu...@chops-service-accounts.iam.gserviceaccount.com
The following revision refers to this bug:
https://chromium.googlesource.com/chromiumos/chromite/+/46da9a8dfce28c96765dc7d061f0c6d7a52e7352
commit 46da9a8dfce28c96765dc7d061f0c6d7a52e7352
Author: George Burgess IV <gbiv@google.com>
Date: Thu Sep 24 12:40:53 2020
lddtree: add LD_ARGV0_REL
Some binaries use `/proc/self/exe` to get a link to the
currently-executing binary. Unfortunately, when `ld.so` is invoked
directly, `/proc/self/exe` alawys points to `ld.so`.
`LD_ARGV0` can only be used to determine the current executable in
programs which haven't changed their working directory from their
starting one, so that's difficult to generally use.
To solve this, this embeds the path of the current binary _relative to
ld.so_ in an env var.
BUG=chromium:1003841, chromium:1114301
TEST=inspected scripts created by cros_setup_toolchains
Change-Id: I1ef1b40206ba683439a8aca90b6812c91a85e7eb
Reviewed-on:https://chromium-review.googlesource.com/c/chromiumos/chromite/+/2424046
Reviewed-by: Bob Haarman <inglorion@chromium.org>
Reviewed-by: Chris McDonald <cjmcdonald@chromium.org>
Commit-Queue: George Burgess <gbiv@chromium.org>
Tested-by: George Burgess <gbiv@chromium.org>
[modify]https://crrev.com/46da9a8dfce28c96765dc7d061f0c6d7a52e7352/third_party/lddtree.py
commit 46da9a8dfce28c96765dc7d061f0c6d7a52e7352
Author: George Burgess IV <gbiv@google.com>
Date: Thu Sep 24 12:40:53 2020
lddtree: add LD_ARGV0_REL
Some binaries use `/proc/self/exe` to get a link to the
currently-executing binary. Unfortunately, when `ld.so` is invoked
directly, `/proc/self/exe` alawys points to `ld.so`.
`LD_ARGV0` can only be used to determine the current executable in
programs which haven't changed their working directory from their
starting one, so that's difficult to generally use.
To solve this, this embeds the path of the current binary _relative to
ld.so_ in an env var.
BUG=chromium:1003841, chromium:1114301
TEST=inspected scripts created by cros_setup_toolchains
Change-Id: I1ef1b40206ba683439a8aca90b6812c91a85e7eb
Reviewed-on:
Reviewed-by: Bob Haarman <inglorion@chromium.org>
Reviewed-by: Chris McDonald <cjmcdonald@chromium.org>
Commit-Queue: George Burgess <gbiv@chromium.org>
Tested-by: George Burgess <gbiv@chromium.org>
[modify]
bu...@chops-service-accounts.iam.gserviceaccount.com
The following revision refers to this bug:
https://chromium.googlesource.com/chromiumos/chromite/+/ca1d761adffc04730cb125907efd4d9cdce26da8
commit ca1d761adffc04730cb125907efd4d9cdce26da8
Author: George Burgess IV <gbiv@google.com>
Date: Tue Oct 06 01:11:14 2020
cros_setup_toolchains: package rust
The cast folks would like to use Rust on these triples. Our support
story for this is captured in the bug (e.g., no guarantees or SLA; all
best-effort). We can also ship on x86_64 flavors, but no one's asked for
it yet, and I'd rather have someone who wants that ask, so we know it'll
actually see use.
BUG=chromium:1114301
TEST=Unpacked a tarball; verified that a working 'hello world' was
produced by the `rustc` within.
Change-Id: I93081c0e6e9aeafe9cf64cc038a76eaedc6ee94e
Reviewed-on:https://chromium-review.googlesource.com/c/chromiumos/chromite/+/2442206
Reviewed-by: Manoj Gupta <manojgupta@chromium.org>
Reviewed-by: Mike Nichols <mikenichols@chromium.org>
Tested-by: George Burgess <gbiv@chromium.org>
Commit-Queue: George Burgess <gbiv@chromium.org>
[modify]https://crrev.com/ca1d761adffc04730cb125907efd4d9cdce26da8/scripts/cros_setup_toolchains.py
commit ca1d761adffc04730cb125907efd4d9cdce26da8
Author: George Burgess IV <gbiv@google.com>
Date: Tue Oct 06 01:11:14 2020
cros_setup_toolchains: package rust
The cast folks would like to use Rust on these triples. Our support
story for this is captured in the bug (e.g., no guarantees or SLA; all
best-effort). We can also ship on x86_64 flavors, but no one's asked for
it yet, and I'd rather have someone who wants that ask, so we know it'll
actually see use.
BUG=chromium:1114301
TEST=Unpacked a tarball; verified that a working 'hello world' was
produced by the `rustc` within.
Change-Id: I93081c0e6e9aeafe9cf64cc038a76eaedc6ee94e
Reviewed-on:
Reviewed-by: Manoj Gupta <manojgupta@chromium.org>
Reviewed-by: Mike Nichols <mikenichols@chromium.org>
Tested-by: George Burgess <gbiv@chromium.org>
Commit-Queue: George Burgess <gbiv@chromium.org>
[modify]
bu...@chops-service-accounts.iam.gserviceaccount.com
The following revision refers to this bug:
https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/d042422cd068b347e44c85f0cb701366051da0f9
commit d042422cd068b347e44c85f0cb701366051da0f9
Author: George Burgess IV <gbiv@google.com>
Date: Tue Oct 06 22:25:44 2020
rust: teach the stdlib about our ld.so trickery
We deliver cross-platform cross-compilers in a trimmed-down chroot-like
environment that doesn't need to ever be `chroot`ed into. chromite's
`lddtree.py` sets this up, but the gist is that all binaries inside of
this chroot are executed like `${chroot}/lib/ld-linux-blah.so --args
"${actual_executable}" "$@"`.
This invocation strategy makes `/proc/self/exe` point to
`ld-linux-blah.so` instead of the ELF executable we're "actually"
invoking.
`lddtree.py` generates scripts which already set a special env var to
point to the "original" `argv[0]`, but that's a path relative to the
directory in which the current program was _initially_ invoked, so
that's not very useful as a general approach.
The intent of this change is to detect if the current binary is being
executed using this ld.so trickery. If it is, we should have an env
var(*) that tells us where the 'original' binary is, relative to ld.so,
so we consult that to find the original binary.
(*) -- once the corresponding change for that lands:
https://chromium-review.googlesource.com/c/chromiumos/chromite/+/2424046
BUG=chromium:1003841, chromium:1114301
TEST=Ran `rustc` in this environment; sysroot was properly detected
Change-Id: I6f6c01f08ad99064614dc0219a0eed2e4f481042
Reviewed-on:https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/2453076
Reviewed-by: LaMont Jones <lamontjones@chromium.org>
Commit-Queue: Mike Nichols <mikenichols@chromium.org>
Tested-by: Mike Nichols <mikenichols@chromium.org>
[rename]https://crrev.com/d042422cd068b347e44c85f0cb701366051da0f9/dev-lang/rust/rust-1.46.0-r1.ebuild
[add]https://crrev.com/d042422cd068b347e44c85f0cb701366051da0f9/dev-lang/rust/files/rust-1.46.0-ld-argv0.patch
commit d042422cd068b347e44c85f0cb701366051da0f9
Author: George Burgess IV <gbiv@google.com>
Date: Tue Oct 06 22:25:44 2020
rust: teach the stdlib about our ld.so trickery
We deliver cross-platform cross-compilers in a trimmed-down chroot-like
environment that doesn't need to ever be `chroot`ed into. chromite's
`lddtree.py` sets this up, but the gist is that all binaries inside of
this chroot are executed like `${chroot}/lib/ld-linux-blah.so --args
"${actual_executable}" "$@"`.
This invocation strategy makes `/proc/self/exe` point to
`ld-linux-blah.so` instead of the ELF executable we're "actually"
invoking.
`lddtree.py` generates scripts which already set a special env var to
point to the "original" `argv[0]`, but that's a path relative to the
directory in which the current program was _initially_ invoked, so
that's not very useful as a general approach.
The intent of this change is to detect if the current binary is being
executed using this ld.so trickery. If it is, we should have an env
var(*) that tells us where the 'original' binary is, relative to ld.so,
so we consult that to find the original binary.
(*) -- once the corresponding change for that lands:
BUG=chromium:1003841, chromium:1114301
TEST=Ran `rustc` in this environment; sysroot was properly detected
Change-Id: I6f6c01f08ad99064614dc0219a0eed2e4f481042
Reviewed-on:
Reviewed-by: LaMont Jones <lamontjones@chromium.org>
Commit-Queue: Mike Nichols <mikenichols@chromium.org>
Tested-by: Mike Nichols <mikenichols@chromium.org>
[rename]
[add]
bu...@chops-service-accounts.iam.gserviceaccount.com
The following revision refers to this bug:
https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/be92fd3fda7e5bcf2b6db3303264b3233d56deb6
commit be92fd3fda7e5bcf2b6db3303264b3233d56deb6
Author: George Burgess IV <gbiv@google.com>
Date: Wed Oct 07 22:03:21 2020
rust: teach the stdlib about our ld.so trickery
We deliver cross-platform cross-compilers in a trimmed-down chroot-like
environment that doesn't need to ever be `chroot`ed into. chromite's
`lddtree.py` sets this up, but the gist is that all binaries inside of
this chroot are executed like `${chroot}/lib/ld-linux-blah.so --args
"${actual_executable}" "$@"`.
This invocation strategy makes `/proc/self/exe` point to
`ld-linux-blah.so` instead of the ELF executable we're "actually"
invoking.
`lddtree.py` generates scripts which already set a special env var to
point to the "original" `argv[0]`, but that's a path relative to the
directory in which the current program was _initially_ invoked, so
that's not very useful as a general approach.
The intent of this change is to detect if the current binary is being
executed using this ld.so trickery. If it is, we should have an env
var(*) that tells us where the 'original' binary is, relative to ld.so,
so we consult that to find the original binary.
(*) -- once the corresponding change for that lands:
https://chromium-review.googlesource.com/c/chromiumos/chromite/+/2424046
BUG=chromium:1003841, chromium:1114301
TEST=Ran `rustc` in this environment; sysroot was properly detected
Change-Id: I6f6c01f08ad99064614dc0219a0eed2e4f481042
Reviewed-on:https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/2423617
Reviewed-by: Mike Nichols <mikenichols@chromium.org>
Reviewed-by: Bob Haarman <inglorion@chromium.org>
Tested-by: Mike Nichols <mikenichols@chromium.org>
[rename]https://crrev.com/be92fd3fda7e5bcf2b6db3303264b3233d56deb6/dev-lang/rust/rust-1.46.0-r1.ebuild
[add]https://crrev.com/be92fd3fda7e5bcf2b6db3303264b3233d56deb6/dev-lang/rust/files/rust-1.46.0-ld-argv0.patch
commit be92fd3fda7e5bcf2b6db3303264b3233d56deb6
Author: George Burgess IV <gbiv@google.com>
Date: Wed Oct 07 22:03:21 2020
rust: teach the stdlib about our ld.so trickery
We deliver cross-platform cross-compilers in a trimmed-down chroot-like
environment that doesn't need to ever be `chroot`ed into. chromite's
`lddtree.py` sets this up, but the gist is that all binaries inside of
this chroot are executed like `${chroot}/lib/ld-linux-blah.so --args
"${actual_executable}" "$@"`.
This invocation strategy makes `/proc/self/exe` point to
`ld-linux-blah.so` instead of the ELF executable we're "actually"
invoking.
`lddtree.py` generates scripts which already set a special env var to
point to the "original" `argv[0]`, but that's a path relative to the
directory in which the current program was _initially_ invoked, so
that's not very useful as a general approach.
The intent of this change is to detect if the current binary is being
executed using this ld.so trickery. If it is, we should have an env
var(*) that tells us where the 'original' binary is, relative to ld.so,
so we consult that to find the original binary.
(*) -- once the corresponding change for that lands:
BUG=chromium:1003841, chromium:1114301
TEST=Ran `rustc` in this environment; sysroot was properly detected
Change-Id: I6f6c01f08ad99064614dc0219a0eed2e4f481042
Reviewed-on:
Reviewed-by: Mike Nichols <mikenichols@chromium.org>
Reviewed-by: Bob Haarman <inglorion@chromium.org>
Tested-by: Mike Nichols <mikenichols@chromium.org>
[rename]
[add]
gb...@google.com
aarch64-cros-linux-gnu-2020.10.07.162959.tar.xz and armv7a-cros-linux-gnueabihf-2020.10.07.162959.tar.xz have functioning `rustc`s and related libs. (both in gs://chromiumos-sdk/2020/10)
please note that these both still require that the native cross-compilers (i.e., ${tar_file_root}/{bin,usr/bin}) are on your $PATH. otherwise, I think they should work. PTAL and let me know if anything's missing, but I thiiiiink this is fixed now?
please note that these both still require that the native cross-compilers (i.e., ${tar_file_root}/{bin,usr/bin}) are on your $PATH. otherwise, I think they should work. PTAL and let me know if anything's missing, but I thiiiiink this is fixed now?
yf...@google.com
Thanks a lot! I will give it a try.
Description
Chrome Version: generic
OS: generic Linux, for cast platforms
Be able to cross compile rust projects for cast platforms using cros toolchains. Need to have rust runtime libraries as well.
e.g.
"rustc --print target-list" could have "aarch64-cros-linux-gnu" and "armv7a-cros-linux-gnueabihf" support. (release version of rustc cannot insert customized targets, we can accept customized rustc.)
rust runtime libraries could be based on selected glibc runtime libraries. e.g. "2.27-r12"