-
Notifications
You must be signed in to change notification settings - Fork 14.3k
[LLD] [COFF] Prefer paths specified with -libpath: over toolchain paths #78039
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
Conversation
@llvm/pr-subscribers-lld @llvm/pr-subscribers-platform-windows Author: Martin Storsjö (mstorsjo) ChangesThe main reason for adding the toolchain paths early was to prefer libraries from the toolchain over ones from MSVC (primarily for compiler-rt builtins). But if the user specifies a directory explicitly with the -libpath: option, that should be preferred over the built-in default paths. This fixes an issue raised at Full diff: https://github.com/llvm/llvm-project/pull/78039.diff 2 Files Affected:
diff --git a/lld/COFF/Driver.cpp b/lld/COFF/Driver.cpp
index cd2985b035bc0d..ca5de2dc02fc3d 100644
--- a/lld/COFF/Driver.cpp
+++ b/lld/COFF/Driver.cpp
@@ -1548,14 +1548,14 @@ void LinkerDriver::linkerMain(ArrayRef<const char *> argsArr) {
{
llvm::TimeTraceScope timeScope2("Search paths");
searchPaths.emplace_back("");
+ for (auto *arg : args.filtered(OPT_libpath))
+ searchPaths.push_back(arg->getValue());
if (!config->mingw) {
// Prefer the Clang provided builtins over the ones bundled with MSVC.
// In MinGW mode, the compiler driver passes the necessary libpath
// options explicitly.
addClangLibSearchPaths(argsArr[0]);
}
- for (auto *arg : args.filtered(OPT_libpath))
- searchPaths.push_back(arg->getValue());
if (!config->mingw) {
// Don't automatically deduce the lib path from the environment or MSVC
// installations when operating in mingw mode. (This also makes LLD ignore
diff --git a/lld/test/COFF/print-search-paths.s b/lld/test/COFF/print-search-paths.s
index 463cc55a793740..8c4df160924192 100644
--- a/lld/test/COFF/print-search-paths.s
+++ b/lld/test/COFF/print-search-paths.s
@@ -1,10 +1,11 @@
# REQUIRES: x86
# RUN: llvm-mc -triple x86_64-windows-msvc %s -filetype=obj -o %t.obj
-# RUN: lld-link -safeseh:no /dll /noentry /winsysroot:%t.dir/sysroot /vctoolsversion:1.1.1.1 /winsdkversion:10.0.1 %t.obj -print-search-paths | FileCheck -DSYSROOT=%t.dir %s
+# RUN: lld-link -safeseh:no /dll /noentry /winsysroot:%t.dir/sysroot /vctoolsversion:1.1.1.1 /winsdkversion:10.0.1 /libpath:custom-dir %t.obj -print-search-paths | FileCheck -DSYSROOT=%t.dir %s
# RUN: llvm-mc -triple i686-windows-msvc %s -filetype=obj -o %t_32.obj
# RUN: lld-link -safeseh:no /dll /noentry /winsysroot:%t.dir/sysroot /vctoolsversion:1.1.1.1 /winsdkversion:10.0.1 %t_32.obj -print-search-paths | FileCheck -DSYSROOT=%t.dir -check-prefix=X86 %s
# CHECK: Library search paths:
# CHECK-NEXT: (cwd)
+# CHECK-NEXT: custom-dir
# CHECK-NEXT: [[CPATH:.*]]lib{{[/\\]}}clang{{[/\\]}}{{[0-9]+}}{{[/\\]}}lib{{[/\\]}}windows
# CHECK-NEXT: [[CPATH]]lib{{[/\\]}}clang{{[/\\]}}{{[0-9]+}}{{[/\\]}}lib
# CHECK-NEXT: [[CPATH]]lib
|
@llvm/pr-subscribers-lld-coff Author: Martin Storsjö (mstorsjo) ChangesThe main reason for adding the toolchain paths early was to prefer libraries from the toolchain over ones from MSVC (primarily for compiler-rt builtins). But if the user specifies a directory explicitly with the -libpath: option, that should be preferred over the built-in default paths. This fixes an issue raised at Full diff: https://github.com/llvm/llvm-project/pull/78039.diff 2 Files Affected:
diff --git a/lld/COFF/Driver.cpp b/lld/COFF/Driver.cpp
index cd2985b035bc0d..ca5de2dc02fc3d 100644
--- a/lld/COFF/Driver.cpp
+++ b/lld/COFF/Driver.cpp
@@ -1548,14 +1548,14 @@ void LinkerDriver::linkerMain(ArrayRef<const char *> argsArr) {
{
llvm::TimeTraceScope timeScope2("Search paths");
searchPaths.emplace_back("");
+ for (auto *arg : args.filtered(OPT_libpath))
+ searchPaths.push_back(arg->getValue());
if (!config->mingw) {
// Prefer the Clang provided builtins over the ones bundled with MSVC.
// In MinGW mode, the compiler driver passes the necessary libpath
// options explicitly.
addClangLibSearchPaths(argsArr[0]);
}
- for (auto *arg : args.filtered(OPT_libpath))
- searchPaths.push_back(arg->getValue());
if (!config->mingw) {
// Don't automatically deduce the lib path from the environment or MSVC
// installations when operating in mingw mode. (This also makes LLD ignore
diff --git a/lld/test/COFF/print-search-paths.s b/lld/test/COFF/print-search-paths.s
index 463cc55a793740..8c4df160924192 100644
--- a/lld/test/COFF/print-search-paths.s
+++ b/lld/test/COFF/print-search-paths.s
@@ -1,10 +1,11 @@
# REQUIRES: x86
# RUN: llvm-mc -triple x86_64-windows-msvc %s -filetype=obj -o %t.obj
-# RUN: lld-link -safeseh:no /dll /noentry /winsysroot:%t.dir/sysroot /vctoolsversion:1.1.1.1 /winsdkversion:10.0.1 %t.obj -print-search-paths | FileCheck -DSYSROOT=%t.dir %s
+# RUN: lld-link -safeseh:no /dll /noentry /winsysroot:%t.dir/sysroot /vctoolsversion:1.1.1.1 /winsdkversion:10.0.1 /libpath:custom-dir %t.obj -print-search-paths | FileCheck -DSYSROOT=%t.dir %s
# RUN: llvm-mc -triple i686-windows-msvc %s -filetype=obj -o %t_32.obj
# RUN: lld-link -safeseh:no /dll /noentry /winsysroot:%t.dir/sysroot /vctoolsversion:1.1.1.1 /winsdkversion:10.0.1 %t_32.obj -print-search-paths | FileCheck -DSYSROOT=%t.dir -check-prefix=X86 %s
# CHECK: Library search paths:
# CHECK-NEXT: (cwd)
+# CHECK-NEXT: custom-dir
# CHECK-NEXT: [[CPATH:.*]]lib{{[/\\]}}clang{{[/\\]}}{{[0-9]+}}{{[/\\]}}lib{{[/\\]}}windows
# CHECK-NEXT: [[CPATH]]lib{{[/\\]}}clang{{[/\\]}}{{[0-9]+}}{{[/\\]}}lib
# CHECK-NEXT: [[CPATH]]lib
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah. I guess this is the right move.
lld/COFF/Driver.cpp
Outdated
if (!config->mingw) { | ||
// Prefer the Clang provided builtins over the ones bundled with MSVC. | ||
// In MinGW mode, the compiler driver passes the necessary libpath | ||
// options explicitly. | ||
addClangLibSearchPaths(argsArr[0]); | ||
} | ||
for (auto *arg : args.filtered(OPT_libpath)) | ||
searchPaths.push_back(arg->getValue()); | ||
if (!config->mingw) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be collapsed in the preceding branch?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, right, good point, will update.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated now.
The main reason for adding the toolchain paths early was to prefer libraries from the toolchain over ones from MSVC (primarily for compiler-rt builtins). But if the user specifies a directory explicitly with the -libpath: option, that should be preferred over the built-in default paths. This fixes an issue raised at https://discourse.llvm.org/t/lld-prefers-system-llvm-libraries-to-user-provided-ones-on-windows/76148.
f0165c2
to
28c1e2b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
…hs (llvm#78039) The main reason for adding the toolchain paths early was to prefer libraries from the toolchain over ones from MSVC (primarily for compiler-rt builtins). But if the user specifies a directory explicitly with the -libpath: option, that should be preferred over the built-in default paths. This fixes an issue raised at https://discourse.llvm.org/t/lld-prefers-system-llvm-libraries-to-user-provided-ones-on-windows/76148.
The main reason for adding the toolchain paths early was to prefer libraries from the toolchain over ones from MSVC (primarily for compiler-rt builtins). But if the user specifies a directory explicitly with the -libpath: option, that should be preferred over the built-in default paths.
This fixes an issue raised at
https://discourse.llvm.org/t/lld-prefers-system-llvm-libraries-to-user-provided-ones-on-windows/76148.