Stream: project-ffi-unwind

Topic: c-unwind PR help


view this post on Zulip katelyn martin (Feb 25 2021 at 23:03):

Gah. Another rollup failure. Could someone a bit more familiar with Rust's CI help me out here? The implementation PR has failed twice now in rollup, due to arm-android. I've used both // ignore-arm and // ignore-android but neither of these seem to have actually applied to arm-android.

There's not a way to test this from the PR itself AFAICT, so I don't have an easy way to see if it'll work until Bors returns an error. For reference, the PR lives here: https://github.com/rust-lang/rust/pull/76570

view this post on Zulip BatmanAoD (Kyle Strand) (Feb 25 2021 at 23:13):

Sorry, I have literally no rustc development experience! (I've moved your question to a new topic since it's not really weekly-meeting related.)

view this post on Zulip Amanieu (Feb 26 2021 at 16:55):

There is a way to test this from the PR, but it's a bit subtle. You can modify the CI configuration in .github so that it runs additional targets for pr runs.

view this post on Zulip Amanieu (Feb 26 2021 at 16:55):

(Make sure to revert that before r+ though)

view this post on Zulip katelyn martin (Feb 26 2021 at 17:26):

Oh that's handy! Thank you :smiley:

view this post on Zulip katelyn martin (Feb 27 2021 at 00:58):

Update: That was super helpful, I was able to confirm the failing target passed in my PR. Thank you again so much!

view this post on Zulip katelyn martin (Mar 02 2021 at 17:56):

Hello again. It seems the msvc CI jobs are the last remaining problem with the FFI-unwind implementation.

I've plugged away at this for a bit, but am feeling a bit stuck. I know very, _very_ little about Windows, and am honestly quite unsure of how to proceed with fixing this. While one option would be to ignore those targets outright, that doesn't feel like the right way forward.

Could someone possibly take a look at what could be the trouble here? It boils down to a linking error, because the compiler is attempting to link the foreign functions from add.lib rather than libadd.a.

view this post on Zulip katelyn martin (Mar 02 2021 at 17:57):

For context, I tried fixing this by following the example of src/test/run-make-fulldeps/archive-duplicate-names/foo.rs, but this didn't seem to help much. I'm a bit unfamiliar with the tools.mk system, so any assistance here would be greatly appreciated. Thank you so much :heart:

view this post on Zulip nikomatsakis (Mar 02 2021 at 18:41):

@rylev do you have any suggestions for who might be able to help @katelyn martin here? :point_up:

view this post on Zulip nagisa (Mar 02 2021 at 18:44):

katelyn martin said:

Could someone possibly take a look at what could be the trouble here? It boils down to a linking error, because the compiler is attempting to link the foreign functions from add.lib rather than libadd.a.

Conventionally the static libraries on Windows are named that way (add.lib), so when you say #[link(name = "add", kind = "static")], rustc will look for add.lib when target is Windows.

view this post on Zulip nagisa (Mar 02 2021 at 18:45):

If I were you, I'd just hack the makefile to produce both add.lib and libadd.a for all platforms (initially by just copying the libadd.a to add.lib in the same makefile?)

view this post on Zulip nagisa (Mar 02 2021 at 18:49):

(Another question is whether $(AR) can produce the coff libraries (that's what I believe the .lib files are expected to be formatted as))

view this post on Zulip rylev (Mar 02 2021 at 18:52):

I think what @nagisa has suggested is the right way to go, but I can get someone more specialized in Windows to help, if that would be helpful @katelyn martin

view this post on Zulip katelyn martin (Mar 03 2021 at 00:49):

:pray: Thank you two so much. This helped tremendously.


Last updated: Jan 26 2022 at 08:02 UTC