···185185 "${setHost}.cc=${ccForHost}"
186186 "${setTarget}.cc=${ccForTarget}"
187187188188+ # The Rust compiler build identifies platforms by Rust target
189189+ # name, and later arguments override previous arguments. This
190190+ # means that when platforms differ in configuration but overlap
191191+ # in Rust target name (for instance, `pkgsStatic`), only one
192192+ # setting will be applied for any given option.
193193+ #
194194+ # This is usually mostly harmless, especially as `fastCross`
195195+ # means that we usually only compile `std` in such cases.
196196+ # However, the build does still need to link helper tools for the
197197+ # build platform in that case. This was breaking the Darwin
198198+ # `pkgsStatic` build, as it was attempting to link build tools
199199+ # with the target platform’s static linker, and failing to locate
200200+ # an appropriate static library for `-liconv`.
201201+ #
202202+ # Since the static build does not link anything for the target
203203+ # platform anyway, we put the target linker first so that the
204204+ # build platform linker overrides it when the Rust target names
205205+ # overlap, allowing the helper tools to build successfully.
206206+ #
207207+ # Note that Rust does not remember these settings in the built
208208+ # compiler, so this does not compromise any functionality of the
209209+ # resulting compiler.
210210+ #
211211+ # The longer‐term fix would be to get Rust to use a more nuanced
212212+ # understanding of platforms, such as by explicitly constructing
213213+ # and passing Rust JSON target definitions that let us
214214+ # distinguish the platforms in cases like these. That would also
215215+ # let us supplant various hacks around the wrappers and hooks
216216+ # that we currently need.
217217+ "${setTarget}.linker=${ccForTarget}"
188218 "${setBuild}.linker=${ccForBuild}"
189219 "${setHost}.linker=${ccForHost}"
190190- "${setTarget}.linker=${ccForTarget}"
191220192221 "${setBuild}.cxx=${cxxForBuild}"
193222 "${setHost}.cxx=${cxxForHost}"