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

Can't link to multiple versions of the same crate #2137

Closed
brson opened this issue Apr 6, 2012 · 3 comments
Closed

Can't link to multiple versions of the same crate #2137

brson opened this issue Apr 6, 2012 · 3 comments
Labels
A-linkage Area: linking into static, shared libraries and binaries

Comments

@brson
Copy link
Contributor

brson commented Apr 6, 2012

I'll be checking this in under run-pass/crateresolve2.rs

// xfail-test
// aux-build:crateresolve-1.rs
// aux-build:crateresolve-2.rs
// aux-build:crateresolve-3.rs

mod a {
    use crateresolve(vers = "0.1");
    fn f() { assert crateresolve::f() == 10; }
}

mod b {
    use crateresolve(vers = "0.2");
    fn f() { assert crateresolve::f() == 20; }
}

mod c {
    use crateresolve(vers = "0.3");
    fn f() { assert crateresolve::f() == 30; }
}

fn main() {
    a::f();
    b::f();
    c::f();
}

Some of the errors make me think that #1706 is part of the problem.

@lht
Copy link
Contributor

lht commented Apr 7, 2012

I took a look on this. It seems the problem is version is not encoded in exported symbols, yet. (There is a FIXME on back::link::exported_name). Function crateresolve::f() is exported as _ZN1f16E regardless which version the library is.

And when translating the call expression, trans::base::get_extern_const always uses the first symbol it found, here f() with vesion 1.0.

@lht
Copy link
Contributor

lht commented Apr 7, 2012

Then I guess this depends on #456.

lht added a commit that referenced this issue Apr 7, 2012
@brson
Copy link
Contributor Author

brson commented Apr 8, 2012

Symbols now have both the meta hash and crate version. This works now.

@brson brson closed this as completed Apr 8, 2012
bors added a commit to rust-lang-ci/rust that referenced this issue Sep 22, 2022
explain which targets we support to what extent

This is basically documenting my policy so far: Linux is the target I know best and can spend most time on. Apple is so close to Linux that it can basically ride along without much extra work. I don't have a lot of time to spend on our Windows support.

Of course, if people commit to contributing and maintaining support for a target, we can promise more than what is documented here. :)  But this is what I am willing to promise.

Also reduce the amount of work we do on the Windows test runner, since that one currently takes 10min longer than the other two.

r? `@oli-obk`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-linkage Area: linking into static, shared libraries and binaries
Projects
None yet
Development

No branches or pull requests

2 participants