It's not unusual for custom cc_toolchains to use a custom c++ compiler sysroot with a libc.so.6.
Currently, proc-macro crates inherit CcLink args. This means that proc-macros might require a different GLIBC version, and fail during the dlsym call by rustc, since it tries to link in the system libc.so
One way to fix this is to recompile a custom toolchain so that proc-macros can be safely compiled and loaded against the custom sysroot libc, but a better solution IMO would be an experimental option to link proc-macros with the self-contained linker. Then rules_rust wouldn't have the requirement that rustc be compiled from source by the same c++ toolchain that links proc macro crates.
It's not unusual for custom cc_toolchains to use a custom c++ compiler sysroot with a libc.so.6.
Currently, proc-macro crates inherit CcLink args. This means that proc-macros might require a different GLIBC version, and fail during the dlsym call by rustc, since it tries to link in the system libc.so
One way to fix this is to recompile a custom toolchain so that proc-macros can be safely compiled and loaded against the custom sysroot libc, but a better solution IMO would be an experimental option to link proc-macros with the self-contained linker. Then rules_rust wouldn't have the requirement that rustc be compiled from source by the same c++ toolchain that links proc macro crates.