Move codegen backend dylibs to a more sensible place

[bjorn3]

They used to be located at lib/rustlib/$HOST_TRIPLE/codegen-backends. Now they are at lib/codegen-backends.

cc @khyperia (EmbarkStudios/rust-gpu#48 (comment))

@rustbot modify labels: +A-driver +T-compiler

[rust-highfive]

r? @matthewjasper

(rust_highfive has picked a reviewer for you, use r? to override)

[Mark-Simulacrum]

Hm, I seem to recall some conversation about the current location being somewhat beneficial for e.g. distros who install Rust and don't want a lib/codegen-backends directory. But those discussions were a while back -- maybe @alexcrichton or @cuviper have some relevant context here?

r? @Mark-Simulacrum

[bjorn3]

Maybe it can be in lib/rustlib/codegen-backends instead then?

[alexcrichton]

Ah sorry, I don't remember much about those discussions myself 👍

[cuviper]

I don't remember past discussions either. But if we start from lib as a common path, likely /usr/lib, then I think:

• lib/ -- nice that it's in the library search path, but way too broad to be looking for plugins
• lib/codegen-backends -- no indication that this belongs to Rust
• lib/rustlib/... -- nice as a purposeful directory. Could have been lib/rust, but probably not worth changing now.
  • lib/rustlib/codegen-backends -- seems okay, but doesn't reflect the host it's built for.
  • lib/rustlib/$host/codegen-backends -- status quo, what's wrong with this?

Some prior art:

$ gcc -print-file-name=plugin
/usr/lib/gcc/x86_64-redhat-linux/10/plugin

[bjorn3]

Currently bin/rustc, lib/librustc_driver-*.so and lib/libLLVM-*.so are already only for a single host. To me lib/rustlib/$target is for the target you are compiling for, not the host you are compiling on. There could be multiple lib/rustlib/$target or even none, but only one codegen-backends dir.

[Mark-Simulacrum]

I think the lib/libLLVM and lib/rustc_driver could be host specific, though, right? If you had bin/rustc-i686 and bin/rustc-x86_64 you could arrange for the .so's to still be found (e.g., in lib32 and lib64 directories or at different filenames potentially).

[bjorn3]

lib/libLLVM and lib/rustc_driver are only used together with the rustc binary, which isn't in an architecture specific location. If you try to use rustc_driver as dependency, the version in lib/rustlib/lib/$target is used, not the one in lib.

[Mark-Simulacrum]

Right, I'm saying that I would expect it to be possible for e.g. debian to have i686 and x86_64 host rustc's installed side-by-side. (Even if that would be somewhat unusual, as rustc is a cross-compiler). Ultimately I think it probably doesn't matter that much...

[Dylan-DPC-zz]

@bjorn3 any updates?

[crlf0710]

@bjorn3 I'm gonna close this due to inactivity. Feel free to reopen or create a new PR when you have time to work on this again. Thanks!