-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
linker: Pass fewer search directories to the linker #128370
Conversation
@bors try |
linker: Pass fewer search directories to the linker Work in progress. try-job: dist-x86_64-musl try-job: dist-x86_64-mingw try-job: dist-x86_64-msvc try-job: dist-x86_64-apple try-job: dist-various-1 try-job: dist-various-2
This comment has been minimized.
This comment has been minimized.
This comment was marked as resolved.
This comment was marked as resolved.
@bors try |
linker: Pass fewer search directories to the linker Work in progress. try-job: dist-x86_64-musl try-job: dist-x86_64-mingw try-job: dist-x86_64-msvc try-job: dist-x86_64-apple try-job: dist-various-1 try-job: dist-various-2
r? @bjorn3 |
☀️ Try build successful - checks-actions |
Makes sense. @bors r+ |
linker: Pass fewer search directories to the linker - The logic for passing `-L` directories to the linker is consolidated in a single function, so the search priorities are immediately clear. - Only `-Lnative=`, `-Lframework=` `-Lall=` directories are passed to linker, but not `-Lcrate=` and others. That's because only native libraries are looked up by name by linker, all Rust crates are passed using full paths, and their directories should not interfere with linker search paths. - The main sysroot library directory shouldn't generally be passed because it shouldn't contain native libraries, except for one case which is now marked with a FIXME. - This also helps with rust-lang#123436, in which we need to walk the same list of directories manually. The next step is to migrate `find_native_static_library` to exactly the same set and order of search directories (which may be a bit annoying for the `iOSSupport` directories rust-lang#121430 (comment)).
This comment has been minimized.
This comment has been minimized.
💔 Test failed - checks-actions |
Sanitizers are also shipped in the sysroot library directory and linked by name on some targets. |
☀️ Test successful - checks-actions |
Finished benchmarking commit (edc4dc3): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results (primary -3.4%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 758.691s -> 760.453s (0.23%) |
…-mingw-import-libraries, r=petrochenkov linker: Allow MSVC to use import libraries following the Meson/MinGW convention Hi all, This PR implements support for `MsvcLinker` to use import libraries following Meson and the MinGW toolchain's naming convention. Meson [follows the `libfoo.dll.a` naming convention](https://mesonbuild.com/FAQ.html#why-does-building-my-project-with-msvc-output-static-libraries-called-libfooa) to disambiguate between static and import libraries. This support already existed for static libraries (see rust-lang#100101), but not for dynamic libraries. The latter case was added by duplicating the logic in `native_libs::find_native_static_library`, but a separate case was added in `link_dylib_by_name` for the Windows CRT libraries which must be handled by the linker itself. See for prerequisites rust-lang#129366, rust-lang#126094, and rust-lang#128370. All feedback is appreciated! Fixes rust-lang#122455 cc `@sdroege` `@nirbheek`
…-mingw-import-libraries, r=petrochenkov linker: Allow MSVC to use import libraries following the Meson/MinGW convention Hi all, This PR implements support for `MsvcLinker` to use import libraries following Meson and the MinGW toolchain's naming convention. Meson [follows the `libfoo.dll.a` naming convention](https://mesonbuild.com/FAQ.html#why-does-building-my-project-with-msvc-output-static-libraries-called-libfooa) to disambiguate between static and import libraries. This support already existed for static libraries (see rust-lang#100101), but not for dynamic libraries. The latter case was added by duplicating the logic in `native_libs::find_native_static_library`, but a separate case was added in `link_dylib_by_name` for the Windows CRT libraries which must be handled by the linker itself. See for prerequisites rust-lang#129366, rust-lang#126094, and rust-lang#128370. All feedback is appreciated! Fixes rust-lang#122455 cc `@sdroege` `@nirbheek`
…nd-mingw-import-libraries, r=petrochenkov linker: Allow MSVC to use import libraries following the Meson/MinGW convention Hi all, This PR implements support for `MsvcLinker` to use import libraries following Meson and the MinGW toolchain's naming convention. Meson [follows the `libfoo.dll.a` naming convention](https://mesonbuild.com/FAQ.html#why-does-building-my-project-with-msvc-output-static-libraries-called-libfooa) to disambiguate between static and import libraries. This support already existed for static libraries (see rust-lang#100101), but not for dynamic libraries. The latter case was added by duplicating the logic in `native_libs::find_native_static_library`, but a separate case was added in `link_dylib_by_name` for the Windows CRT libraries which must be handled by the linker itself. See for prerequisites rust-lang#129366, rust-lang#126094, and rust-lang#128370. All feedback is appreciated! Fixes rust-lang#122455 cc `@sdroege` `@nirbheek`
Rollup merge of rust-lang#123436 - amyspark:allow-msvc-to-use-meson-and-mingw-import-libraries, r=petrochenkov linker: Allow MSVC to use import libraries following the Meson/MinGW convention Hi all, This PR implements support for `MsvcLinker` to use import libraries following Meson and the MinGW toolchain's naming convention. Meson [follows the `libfoo.dll.a` naming convention](https://mesonbuild.com/FAQ.html#why-does-building-my-project-with-msvc-output-static-libraries-called-libfooa) to disambiguate between static and import libraries. This support already existed for static libraries (see rust-lang#100101), but not for dynamic libraries. The latter case was added by duplicating the logic in `native_libs::find_native_static_library`, but a separate case was added in `link_dylib_by_name` for the Windows CRT libraries which must be handled by the linker itself. See for prerequisites rust-lang#129366, rust-lang#126094, and rust-lang#128370. All feedback is appreciated! Fixes rust-lang#122455 cc `@sdroege` `@nirbheek`
-L
directories to the linker is consolidated in a single function, so the search priorities are immediately clear.-Lnative=
,-Lframework=
-Lall=
directories are passed to linker, but not-Lcrate=
and others. That's because only native libraries are looked up by name by linker, all Rust crates are passed using full paths, and their directories should not interfere with linker search paths.The next step is to migrate
find_native_static_library
to exactly the same set and order of search directories (which may be a bit annoying for theiOSSupport
directories #121430 (comment)).