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

archiver in freebsd images appears to be broken #1100

Closed
4 of 11 tasks
nagisa opened this issue Oct 30, 2022 · 4 comments · Fixed by #1105
Closed
4 of 11 tasks

archiver in freebsd images appears to be broken #1100

nagisa opened this issue Oct 30, 2022 · 4 comments · Fixed by #1105
Labels
A-bsd Area: BSD-family targets bug c-cpp-deps-issue

Comments

@nagisa
Copy link
Contributor

nagisa commented Oct 30, 2022

Checklist

Describe your issue

The toolchain used in the freebsd images appears to be broken. I managed to reduce the test case basically down to just:

$ docker pull ghcr.io/cross-rs/x86_64-unknown-freebsd:0.2.4
$ docker run -it ghcr.io/cross-rs/x86_64-unknown-freebsd:0.2.4 bash
$ echo "int banana(void) { return 0; }" | x86_64-unknown-freebsd12-gcc -xc - -c -o chaenomeles.o
$ x86_64-unknown-freebsd12-gcc-ar cq mango.ar chaenomeles.o; echo $?
x86_64-unknown-freebsd12-gcc-ar: Cannot find plugin 'liblto_plugin.so'
1

This in practice causes crates such as cc fail to package the built objects into an .a in crates’ build.rs scripts.

What target(s) are you cross-compiling for?

i686-unknown-freebsd, x86_64-unknown-freebsd

Which operating system is the host (e.g computer cross is on) running?

  • macOS
  • Windows
  • Linux / BSD
  • other OS (specify in description)

What architecture is the host?

  • x86_64 / AMD64
  • arm32
  • arm64 (including Mac M1)

What container engine is cross using?

  • docker
  • podman
  • other container engine (specify in description)

cross version

cross 0.2.4

Example

No response

Additional information / notes

The closest relevant thing I can find on the internet is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81326. Curiously we are already building the toolchain with --disable-lto flag, so it might be a bug in gcc itself?

@Alexhuszagh
Copy link
Contributor

Alexhuszagh commented Oct 30, 2022

It works if we use x86_64-unknown-freebsd12-ar rather than x86_64-unknown-freebsd12-gcc-ar, which means this should be fixed if we provide AR_x86_64_unknown_freebsd=x86_64-unknown-freebsd12-ar as an environment variable in the Dockerfile.

@nagisa can you confirm the following works for your cross build:
EDIT: See below.

Cross.toml

[target.x86_64-unknown-freebsd]
dockerfile = "./Dockerfile.x86_64-unknown-freebsd"

And then for Dockerfile.x86_64-unknown-freebsd:

FROM ghcr.io/cross-rs/x86_64-unknown-freebsd:0.2.4
ENV AR_x86_64_unknown_freebsd=x86_64-unknown-freebsd12-ar

@Emilgardis
Copy link
Member

Emilgardis commented Oct 30, 2022

or just

[target.x86_64-unknown-freebsd.env]
passthrough = ["AR_x86_64_unknown_freebsd=x86_64-unknown-freebsd12-ar"]

@nagisa
Copy link
Contributor Author

nagisa commented Oct 30, 2022

Aha, curious. This seems like it is potentially an issue cc-rs might be interested in in the first place, given its preference towards the -gcc-ar suffix.

https://github.com/rust-lang/cc-rs/blob/2d5cc704dfafad16c873e386244181118cb5e4d1/src/lib.rs#L2623-L2638

and this is a very recent change too (rust-lang/cc-rs#735).

But otherwise yeah setting the environment variable does work.

nagisa added a commit to nagisa/gcc-rs that referenced this issue Oct 30, 2022
As observed in cross-rs/cross#1100, in some
situations `*-gcc-ar` might actually be just broken.

I believe this is most likely just a plain bug in gcc (failing to
consider `--disable-lto` configuration option somewhere in their build
setup,) but for the time being `*-ar` tends to avoid this problem
altogether.

Code added in rust-lang#736 appears to be
preferring `*-gcc-ar`, but no strong rationale is given to prefer one
over the other. `*-gcc-ar` being outright broken sometimes seems like a
rationale strong enough to continue preferring binutils’ `ar`.
thomcc pushed a commit to rust-lang/cc-rs that referenced this issue Oct 31, 2022
As observed in cross-rs/cross#1100, in some
situations `*-gcc-ar` might actually be just broken.

I believe this is most likely just a plain bug in gcc (failing to
consider `--disable-lto` configuration option somewhere in their build
setup,) but for the time being `*-ar` tends to avoid this problem
altogether.

Code added in #736 appears to be
preferring `*-gcc-ar`, but no strong rationale is given to prefer one
over the other. `*-gcc-ar` being outright broken sometimes seems like a
rationale strong enough to continue preferring binutils’ `ar`.
@Alexhuszagh
Copy link
Contributor

Alexhuszagh commented Nov 1, 2022

This is also broken for solaris. It might be a good idea to provide AR_$target for all non-glibc/musl images since this might affect people with locked cc-rs versions and prior to a new cc-rs release.

bors bot added a commit that referenced this issue Nov 1, 2022
1105: Explicitly prefer `-ar` to `-gcc-ar`. r=Emilgardis a=Alexhuszagh

Fixes #1100.

Co-authored-by: Alex Huszagh <ahuszagh@gmail.com>
@bors bors bot closed this as completed in 1d72f53 Nov 1, 2022
bors bot added a commit that referenced this issue Nov 15, 2022
1138: Explicitly set ar for all targets. r=Emilgardis a=Alexhuszagh

Closes #1137.
Also linked to #1100.

Co-authored-by: Alex Huszagh <ahuszagh@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-bsd Area: BSD-family targets bug c-cpp-deps-issue
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants