"Tamir Duberstein" <tamird@xxxxxxxxx> writes: > Because the `macros` crate exposes procedural macros, it must be > compiled as a dynamic library (so it can be loaded by the compiler at > compile-time). > > Before this change the resulting artifact was always named > `libmacros.so`, which works on hosts where this matches the naming > convention for dynamic libraries. However the proper name on macOS would > be `libmacros.dylib`. > > This turns out to matter even when the dependency is passed with a path > (`--extern macros=path/to/libmacros.so` rather than `--extern macros`) > because rustc uses the file name to infer the type of the library (see > link). This is because there's no way to specify both the path to and > the type of the external library via CLI flags. The compiler could > speculatively parse the file to determine its type, but it does not do > so today. > > This means that libraries that match neither rustc's naming convention > for static libraries nor the platform's naming convention for dynamic > libraries are *rejected*. > > The only solution I've found is to follow the host platform's naming > convention. This patch does that by querying the compiler to determine > the appropriate name for the artifact. This allows the kernel to build > with CONFIG_RUST=y on macOS. > > Link: https://github.com/rust-lang/rust/blob/d829780/compiler/rustc_metadata/src/locator.rs#L728-L752 > Tested-by: Daniel Gomez <da.gomez@xxxxxxxxxxx> > Co-developed-by: Fiona Behrens <me@xxxxxxxxxx> > Signed-off-by: Fiona Behrens <me@xxxxxxxxxx> > Signed-off-by: Tamir Duberstein <tamird@xxxxxxxxx> I don't have a mac to test on, but this does not break anything for me when building with rust enabled on linux. Tested-by: Andreas Hindborg <a.hindborg@xxxxxxxxxx> Best regards, Andreas Hindborg
