Stream: t-compiler

Topic: dylib linking breakage


pnkfelix (Dec 05 2019 at 16:05, on Zulip):

spawned off T-compiler meeting discussion

pnkfelix (Dec 05 2019 at 16:07, on Zulip):

context: there's discussion of breakage injected by PR #59752

pnkfelix (Dec 05 2019 at 16:07, on Zulip):

see e.g. this comment: https://github.com/rust-lang/rust/pull/59752#issuecomment-554628486

pnkfelix (Dec 05 2019 at 16:07, on Zulip):

which links to a number of issues that provide examples of things that "broke"

pnkfelix (Dec 05 2019 at 16:07, on Zulip):

but some (perhaps all?) of these were using unsupported use cases

pnkfelix (Dec 05 2019 at 16:08, on Zulip):

I've self-assigned #65610 to myself for further investigation

mw (Dec 05 2019 at 16:08, on Zulip):

it would be interesting to know if there is any public documentation that specifies what Rust dylib is?

pnkfelix (Dec 05 2019 at 16:08, on Zulip):

I've been dying to research this

pnkfelix (Dec 05 2019 at 16:09, on Zulip):

I can feel it ... its coming ... I might have to draft yet another epic blog post

mw (Dec 05 2019 at 16:09, on Zulip):

as far as I know, we don't even guarantee that it is a proper shared library/DLL

simulacrum (Dec 05 2019 at 16:09, on Zulip):

AFAIK, we have not only no public documentation but we don't even have internal documentation (i.e., not even in our heads)

pnkfelix (Dec 05 2019 at 16:09, on Zulip):

/me cannot wait to interview graydon

nikomatsakis (Dec 05 2019 at 16:09, on Zulip):

Yes, I think there are lots of unknowns, but I'm not entirely comfortable with the breakage we're seeing

nikomatsakis (Dec 05 2019 at 16:09, on Zulip):

I thnk @Alex Crichton might have "the best" picture of the history here?

nikomatsakis (Dec 05 2019 at 16:09, on Zulip):

I guess I feel like:

mw (Dec 05 2019 at 16:10, on Zulip):

similar to RLIBs where we reserve the right to make them MIR-only at some point

nikomatsakis (Dec 05 2019 at 16:10, on Zulip):

I'd be more comfortable with the breakage if we had an RFC or an announced plan

nikomatsakis (Dec 05 2019 at 16:10, on Zulip):

that we had "designed"

nikomatsakis (Dec 05 2019 at 16:10, on Zulip):

or at least that we were evolving

nikomatsakis (Dec 05 2019 at 16:10, on Zulip):

so we could point people at it

pnkfelix (Dec 05 2019 at 16:10, on Zulip):

something other than "we'll keep the use of dylib in rustc working, by some means. The rest of you are on your own"

nikomatsakis (Dec 05 2019 at 16:11, on Zulip):

@nagisa's comments on https://github.com/rust-lang/rust/issues/65610 made it sound like a lot of crates would be affected?

nikomatsakis (Dec 05 2019 at 16:11, on Zulip):

not really sure what a lot is here

nikomatsakis (Dec 05 2019 at 16:11, on Zulip):

and I wasn't clear if this was limited to windows-gnu?

pnkfelix (Dec 05 2019 at 16:11, on Zulip):

well its already landed, as a stable-to-stable regression

nikomatsakis (Dec 05 2019 at 16:11, on Zulip):

ok, s/would be/are/

pnkfelix (Dec 05 2019 at 16:11, on Zulip):

so presumably we're already seeing the fallout

nikomatsakis (Dec 05 2019 at 16:12, on Zulip):

I'm referring to this comment:

Okay, that’s somewhat bad, then, because libraries that rely exclusively on arguments emitted by cc for linking purposes are very abound in the ecosystem.

nikomatsakis (Dec 05 2019 at 16:12, on Zulip):

well, some part of the fallout anyway

nikomatsakis (Dec 05 2019 at 16:12, on Zulip):

anyway the truth is I have no idea what the right behavior is here

nikomatsakis (Dec 05 2019 at 16:12, on Zulip):

but I bet folks like @Josh Triplett etc might have some instincts for it

Alex Crichton (Dec 05 2019 at 16:13, on Zulip):

This sort of change falls in line with how we don't in general give a ton of control to users about symbols and such, and it may be best solved by adding a flag or something like that to disable the behavior. I think it's true though that dylib has generally been designed historically as "so long as rustc keeps working, anything else goes"

nagisa (Dec 05 2019 at 16:13, on Zulip):

Me neither ;) I always thought #[link] was optional, and based on what I’ve seen in ecosystem, others did so too. The largest problem with that notion is that things mostly work most of the time and only start failing in certain scenarios when you omit it.

pnkfelix (Dec 05 2019 at 16:13, on Zulip):

hmm. I wonder if the scope of the "parity with C" working group is solely restricted to cdylibs, or if they are interested in dylibs too

nikomatsakis (Dec 05 2019 at 16:13, on Zulip):

@nagisa can you confirm whether this fallout is specific to windows-gnu?

nagisa (Dec 05 2019 at 16:14, on Zulip):

It is not windows-gnu specific.

mw (Dec 05 2019 at 16:14, on Zulip):

does C++ have shared libraries?

mw (Dec 05 2019 at 16:14, on Zulip):

or do they all go through a C interface?

mw (Dec 05 2019 at 16:15, on Zulip):

/me has to run too

nikomatsakis (Dec 05 2019 at 16:16, on Zulip):

It is not windows-gnu specific.

how does that come about, when the PR in question only changes the behavior of windows-gnu? Or is the PR description misleading me?

This makes windows-gnu match the behavior of windows-msvc. It probably doesn't make sense to export these symbols on other platforms either.

nikomatsakis (Dec 05 2019 at 16:16, on Zulip):

I guess, reading the code, that it is, it certainly seems to make more general changes.

Zoxc (Dec 05 2019 at 16:16, on Zulip):

It was changed to affect all platforms.

nikomatsakis (Dec 05 2019 at 16:18, on Zulip):

OK I see I see

Zoxc (Dec 05 2019 at 16:22, on Zulip):

We can probably count extern functions as being exported to avoid having using link attributes, assuming linkers allow you to specify functions which don't exist to be exported.

pnkfelix (Dec 05 2019 at 16:27, on Zulip):

(at least extern functions used by any methods that are not marked #[inline(never)] ...?)

nikomatsakis (Dec 05 2019 at 16:31, on Zulip):

OK. I don't really have a strong opinion as to the proper answer here, as I said, but I kind of feel like we should try to write-up an RFC with a plan and decide that way (personally). Making arbitrary changes at this point without having had public discussion feels not great.

Josh Triplett (Dec 05 2019 at 16:55, on Zulip):

@pnkfelix Parity with C would only apply to cdylib or staticlib.

mw (Dec 06 2019 at 09:27, on Zulip):

OK. I don't really have a strong opinion as to the proper answer here, as I said, but I kind of feel like we should try to write-up an RFC with a plan and decide that way (personally). Making arbitrary changes at this point without having had public discussion feels not great.

Yes, I want to second that. I'm sure there are ways to rejigger things until most of the reported problems go away but the real issue is that don't have a specification of what is and what isn't supported and there is no public documentation of the fact that nothing at all can be expected from Rust dylibs.

Last update: Jul 03 2020 at 17:55UTC