starred/rspotify

Fork 0

mirror of https://github.com/ramsayleung/rspotify.git synced 2026-04-25 23:45:52 +03:00

[GH-ISSUE #183] CI suddenly not working #62

New issue

Closed

opened 2026-02-27 20:22:53 +03:00 by kerem · 5 comments

kerem commented

2026-02-27 20:22:53 +03:00

Owner

Originally created by @marioortizmanero on GitHub (Feb 12, 2021).
Original GitHub issue: https://github.com/ramsayleung/rspotify/issues/183

Describe the bug

Seems like the CI has stopped passing suddenly for cross-compilation on all platforms for reqwest. This has started happening in https://github.com/ramsayleung/rspotify/pull/182. I'm unable to reproduce on my current platform, without cross-compilation, on a x86_64 GNU/Linux.

I suspect it's due to https://github.com/ramsayleung/rspotify/pull/175, since the linking errors are similar to when the Tokio upgrade failed, see https://github.com/ramsayleung/rspotify/issues/164.

I'll investigate and try to see what's causing it.

Originally created by @marioortizmanero on GitHub (Feb 12, 2021). Original GitHub issue: https://github.com/ramsayleung/rspotify/issues/183 **Describe the bug** Seems like [the CI](https://github.com/ramsayleung/rspotify/runs/1886272410) has stopped passing suddenly for cross-compilation on all platforms for reqwest. This has started happening in https://github.com/ramsayleung/rspotify/pull/182. I'm unable to reproduce on my current platform, without cross-compilation, on a x86_64 GNU/Linux. I suspect it's due to https://github.com/ramsayleung/rspotify/pull/175, since the linking errors are similar to when the Tokio upgrade failed, see https://github.com/ramsayleung/rspotify/issues/164. I'll investigate and try to see what's causing it.

kerem

2026-02-27 20:22:53 +03:00

closed this issue
added the
help wanted

bug
labels

kerem commented

2026-02-27 20:22:54 +03:00

Author

Owner

@marioortizmanero commented on GitHub (Feb 12, 2021):

Can confirm that this doesn't happen when downgrading to reqwest 0.10.7

reqwest 0.11 upgraded hyper to v0.14, so it might be related to that.

@marioortizmanero commented on GitHub (Feb 12, 2021): Can confirm that this doesn't happen when downgrading to reqwest 0.10.7 reqwest 0.11 upgraded hyper to v0.14, so it might be related to that.

kerem commented

2026-02-27 20:22:54 +03:00

Author

Owner

@marioortizmanero commented on GitHub (Feb 12, 2021):

I've opened an issue at https://github.com/hyperium/hyper/issues/2434, since it seems to be related to hyper.

@marioortizmanero commented on GitHub (Feb 12, 2021): I've opened an issue at https://github.com/hyperium/hyper/issues/2434, since it seems to be related to hyper.

kerem commented

2026-02-27 20:22:54 +03:00

Author

Owner

@marioortizmanero commented on GitHub (Feb 12, 2021):

I've finally found out why it doesn't work: starting at some commit from hyper it won't compile unless you run export CARGO_TARGET_AARCH64_UNKNOWN_LINUX_GNU_LINKER=aarch64-linux-gnu-gcc. I found this in cross' Dockerfile for this architecture, see https://github.com/rust-embedded/cross/blob/master/docker/Dockerfile.aarch64-unknown-linux-gnu.

To avoid these kind of issues and complicated installations, shall we try to use cross instead of cargo, @ramsayleung? It includes dockerfiles with the required dependencies and such. That, or just stop cross-compilating. Not sure if we should be worring about these kind of issues in such a high level library.

@marioortizmanero commented on GitHub (Feb 12, 2021): I've finally found out why it doesn't work: starting at some commit from hyper it won't compile unless you run `export CARGO_TARGET_AARCH64_UNKNOWN_LINUX_GNU_LINKER=aarch64-linux-gnu-gcc`. I found this in [cross](https://github.com/rust-embedded/cross)' Dockerfile for this architecture, see https://github.com/rust-embedded/cross/blob/master/docker/Dockerfile.aarch64-unknown-linux-gnu. To avoid these kind of issues and complicated installations, shall we try to use `cross` instead of `cargo`, @ramsayleung? It includes dockerfiles with the required dependencies and such. That, or just stop cross-compilating. Not sure if we should be worring about these kind of issues in such a high level library.

kerem commented

2026-02-27 20:22:54 +03:00

Author

Owner

@ramsayleung commented on GitHub (Feb 12, 2021):

Great to know that you figure out the reason :)

That, or just stop cross-compilating. Not sure if we should be worring about these kind of issues in such a high level library.

About one year ago, Marcel provided new features to support other tls implementations besides openssl in order make it easier to cross compile when using this crate in the PR #76. So I think it would be better to support cross-compiling if possible, since it seems some developers use rspotify in some architectures like ARM.

To avoid these kind of issues and complicated installations, shall we try to use cross instead of cargo

Is it possible to fix this CI issue by exporting this environment variable in Github Action configuration?

export CARGO_TARGET_AARCH64_UNKNOWN_LINUX_GNU_LINKER=aarch64-linux-gnu-gcc

I personally prefer to solve this issue with costing as less as possible, with built-in functionality of cargo, instead of including extra required dependencies :)

@ramsayleung commented on GitHub (Feb 12, 2021): Great to know that you figure out the reason :) > That, or just stop cross-compilating. Not sure if we should be worring about these kind of issues in such a high level library. About one year ago, Marcel provided new features to support other tls implementations besides openssl in order make it easier to cross compile when using this crate in the PR #76. So I think it would be better to support cross-compiling if possible, since it seems some developers use `rspotify` in some architectures like ARM. > To avoid these kind of issues and complicated installations, shall we try to use `cross` instead of `cargo` Is it possible to fix this CI issue by exporting this environment variable in Github Action configuration? ```sh export CARGO_TARGET_AARCH64_UNKNOWN_LINUX_GNU_LINKER=aarch64-linux-gnu-gcc ``` I personally prefer to solve this issue with costing as less as possible, with built-in functionality of `cargo`, instead of including extra required dependencies :)

kerem commented

2026-02-27 20:22:54 +03:00

Author

Owner

@marioortizmanero commented on GitHub (Feb 12, 2021):

About one year ago, Marcel provided new features to support other tls implementations besides openssl in order make it easier to cross compile when using this crate in the PR #76. So I think it would be better to support cross-compiling if possible, since it seems some developers use rspotify in some architectures like ARM.

Sure! Testing can never be too much :)

Is it possible to fix this CI issue by exporting this environment variable in Github Action configuration?

Yes, but the thing is that you need something similar for each architecture, and they might break in the future again. Meaning that we would have to maintain the cross-compilation setup manually. The dockerfiles from cross also have more env variables we might need in the future. It might "cost" less in terms of overhead, but the workflow file will definitely be smaller, as all that's needed is installing docker and then cross.

To be fair cross might be too much, as it even installs Qemu to run the tests. But we could take advantage of that and do test + build, instead of just build as we're doing right now, if you care about that. If we just keep using build we don't really need cross. Just wanted to consider it.

Otherwise we can just take a look at cross's dockerfiles and copy the interesting parts, which seems to be only an env variable we're missing.

@marioortizmanero commented on GitHub (Feb 12, 2021): > About one year ago, Marcel provided new features to support other tls implementations besides openssl in order make it easier to cross compile when using this crate in the PR #76. So I think it would be better to support cross-compiling if possible, since it seems some developers use rspotify in some architectures like ARM. Sure! Testing can never be too much :) > Is it possible to fix this CI issue by exporting this environment variable in Github Action configuration? Yes, but the thing is that you need something similar for each architecture, and they might break in the future again. Meaning that we would have to maintain the cross-compilation setup manually. The dockerfiles from `cross` also have more env variables we might need in the future. It might "cost" less in terms of overhead, but the workflow file will definitely be smaller, as all that's needed is installing `docker` and then `cross`. To be fair `cross` might be too much, as it even installs Qemu to run the tests. But we could take advantage of that and do `test` + `build`, instead of just `build` as we're doing right now, if you care about that. If we just keep using `build` we don't really need `cross`. Just wanted to consider it. Otherwise we can just take a look at `cross`'s dockerfiles and copy the interesting parts, which seems to be only an env variable we're missing.

kerem referenced this issue

2026-02-27 20:23:49 +03:00

[PR #62] [MERGED] Provide more informational error strings for API #218