Skip to content

[LLD] [MinGW] Reinstate the former spelling in the version message #97698

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

Merged
merged 2 commits into from
Jul 4, 2024

Conversation

mstorsjo
Copy link
Member

@mstorsjo mstorsjo commented Jul 4, 2024

0f9fbbb changed the version printouts. This broke linker detection in Meson, when disambiguating between the ld.lld and lld-link interfaces, in
https://github.com/mesonbuild/meson/blob/1.4.1/mesonbuild/linkers/detect.py#L67, which checks for the string "(compatible with GNU linkers)" including the parentheses.

Reinstate the parentheses in the printout here, for compatibility with Meson. The printout looks a little odd in this form, "LLD 19.0.0 (https://github.com/llvm/llvm-project 173514d) (compatible with GNU linkers)", but works with Meson.

The Meson check should ideally be loosened. But even then, we should only change LLD to the new form once older versions of Meson aren't used for these targets any longer, i.e. earliest within a few years.

@llvmbot llvmbot added the lld label Jul 4, 2024
@llvmbot
Copy link
Member

llvmbot commented Jul 4, 2024

@llvm/pr-subscribers-lld

Author: Martin Storsjö (mstorsjo)

Changes

0f9fbbb changed the version printouts. This broke linker detection in Meson, when disambiguating between the ld.lld and lld-link interfaces, in
https://github.com/mesonbuild/meson/blob/1.4.1/mesonbuild/linkers/detect.py#L67, which checks for the string "(compatible with GNU linkers)" including the parentheses.

Reinstate the parentheses in the printout here, for compatibility with Meson. The printout looks a little odd in this form, "LLD 19.0.0 (https://github.com/llvm/llvm-project 173514d) (compatible with GNU linkers)", but works with Meson.

The Meson check should ideally be loosened. But even then, we should only change LLD to the new form once older versions of Meson aren't used for these targets any longer, i.e. earliest within a few years.


Full diff: https://github.com/llvm/llvm-project/pull/97698.diff

2 Files Affected:

  • (modified) lld/MinGW/Driver.cpp (+1-1)
  • (modified) lld/test/MinGW/driver.test (+1-1)
diff --git a/lld/MinGW/Driver.cpp b/lld/MinGW/Driver.cpp
index 1fd120ad3601d..35fd478a21905 100644
--- a/lld/MinGW/Driver.cpp
+++ b/lld/MinGW/Driver.cpp
@@ -199,7 +199,7 @@ bool link(ArrayRef<const char *> argsArr, llvm::raw_ostream &stdoutOS,
   // a GNU compatible linker. As long as an output for the -v option
   // contains "GNU" or "with BFD", they recognize us as GNU-compatible.
   if (args.hasArg(OPT_v) || args.hasArg(OPT_version))
-    message(getLLDVersion() + ", compatible with GNU linkers");
+    message(getLLDVersion() + " (compatible with GNU linkers)");
 
   // The behavior of -v or --version is a bit strange, but this is
   // needed for compatibility with GNU linkers.
diff --git a/lld/test/MinGW/driver.test b/lld/test/MinGW/driver.test
index 44ec58818e0bf..b723c0ad98749 100644
--- a/lld/test/MinGW/driver.test
+++ b/lld/test/MinGW/driver.test
@@ -268,7 +268,7 @@ APPCONTAINER: -appcontainer
 RUN: ld.lld -m i386pep --version 2>&1 | FileCheck -check-prefix=VERSION %s
 RUN: ld.lld -m i386pep -v 2>&1 | FileCheck -check-prefix=VERSION %s
 RUN: not ld.lld -m i386pep -v xyz 2>&1 | FileCheck -check-prefix=VERSION %s
-VERSION: LLD {{.*}}, compatible with GNU linkers
+VERSION: LLD {{.*}} (compatible with GNU linkers)
 
 RUN: ld.lld -m i386pep --help 2>&1 | FileCheck -check-prefix=HELP %s
 HELP: USAGE:

mstorsjo added a commit to mstorsjo/meson that referenced this pull request Jul 4, 2024
Don't require the string to be enclosed in parentheses.
llvm/llvm-project#97323 changed the LLD
version printout to no longer be enclosed in parentheses, which
made Meson fail to detect the linker style used here.

The LLD change is being reverted in
llvm/llvm-project#97698 in order to fix
building with existing Meson versions, but for the future, loosen
the check slightly, to not require the parentheses.
@@ -268,7 +268,7 @@ APPCONTAINER: -appcontainer
RUN: ld.lld -m i386pep --version 2>&1 | FileCheck -check-prefix=VERSION %s
RUN: ld.lld -m i386pep -v 2>&1 | FileCheck -check-prefix=VERSION %s
RUN: not ld.lld -m i386pep -v xyz 2>&1 | FileCheck -check-prefix=VERSION %s
VERSION: LLD {{.*}}, compatible with GNU linkers
VERSION: LLD {{.*}} (compatible with GNU linkers)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider a link to
mesonbuild/meson#13383

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done, thanks!

eli-schwartz pushed a commit to mesonbuild/meson that referenced this pull request Jul 4, 2024
Don't require the string to be enclosed in parentheses.
llvm/llvm-project#97323 changed the LLD
version printout to no longer be enclosed in parentheses, which
made Meson fail to detect the linker style used here.

The LLD change is being reverted in
llvm/llvm-project#97698 in order to fix
building with existing Meson versions, but for the future, loosen
the check slightly, to not require the parentheses.
mstorsjo added 2 commits July 4, 2024 23:58
0f9fbbb changed the version
printouts. This broke linker detection in Meson, when disambiguating
between the ld.lld and lld-link interfaces, in
https://github.com/mesonbuild/meson/blob/1.4.1/mesonbuild/linkers/detect.py#L67,
which checks for the string "(compatible with GNU linkers)"
including the parentheses.

Reinstate the parentheses in the printout here, for compatibility
with Meson. The printout looks a little odd in this form,
"LLD 19.0.0 (https://github.com/llvm/llvm-project 173514d) (compatible with GNU linkers)",
but works with Meson.

The Meson check should ideally be loosened. But even then, we
should only change LLD to the new form once older versions of
Meson aren't used for these targets any longer, i.e. earliest
within a few years.
@mstorsjo mstorsjo force-pushed the lld-mingw-version-string branch from de9f9de to 3f4cd57 Compare July 4, 2024 21:03
@mstorsjo mstorsjo merged commit b298e2d into llvm:main Jul 4, 2024
4 of 6 checks passed
@mstorsjo mstorsjo deleted the lld-mingw-version-string branch July 4, 2024 21:10
@llvm-ci
Copy link
Collaborator

llvm-ci commented Jul 4, 2024

LLVM Buildbot has detected a new failure on builder lldb-aarch64-windows running on linaro-armv8-windows-msvc-05 while building lld at step 6 "test".

Full details are available at: https://lab.llvm.org/buildbot/#/builders/141/builds/513

Here is the relevant piece of the build log for the reference:

Step 6 (test) failure: build (failure)
...
31.553 [1/2/288] Linking CXX executable tools\lldb\unittests\Thread\ThreadTests.exe
31.622 [1/1/289] Linking CXX executable tools\lldb\unittests\ValueObject\LLDBValueObjectTests.exe
llvm-lit.py: C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\llvm\utils\lit\lit\llvm\config.py:57: note: using lit tools: C:\Users\tcwg\scoop\apps\git\2.39.0.windows.2\usr\bin
llvm-lit.py: C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\llvm\utils\lit\lit\llvm\config.py:508: note: using clang: c:\users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe
llvm-lit.py: C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\llvm\utils\lit\lit\llvm\config.py:508: note: using ld.lld: c:\users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\ld.lld.exe
llvm-lit.py: C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\llvm\utils\lit\lit\llvm\config.py:508: note: using lld-link: c:\users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\lld-link.exe
llvm-lit.py: C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\llvm\utils\lit\lit\llvm\config.py:508: note: using ld64.lld: c:\users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\ld64.lld.exe
llvm-lit.py: C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\llvm\utils\lit\lit\llvm\config.py:508: note: using wasm-ld: c:\users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\wasm-ld.exe
31.623 [0/1/289] R-- Testing: 1985 tests, 2 workers --
Testing:  0.. 10.. 20.. 30.. 40.. 50.
FAIL: lldb-api :: tools/lldb-server/TestGdbRemoteLaunch.py (1148 of 1985)
******************** TEST 'lldb-api :: tools/lldb-server/TestGdbRemoteLaunch.py' FAILED ********************
Script:
--
C:/Users/tcwg/AppData/Local/Programs/Python/Python311-arm64/python.exe C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/llvm-project/lldb\test\API\dotest.py -u CXXFLAGS -u CFLAGS --env OBJCOPY=C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/./bin/llvm-objcopy.exe --env LLVM_LIBS_DIR=C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/./lib --env LLVM_INCLUDE_DIR=C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/include --env LLVM_TOOLS_DIR=C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/./bin --arch aarch64 --build-dir C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/lldb-test-build.noindex --lldb-module-cache-dir C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/lldb-test-build.noindex/module-cache-lldb\lldb-api --clang-module-cache-dir C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/lldb-test-build.noindex/module-cache-clang\lldb-api --executable C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/./bin/lldb.exe --compiler C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/./bin/clang.exe --dsymutil C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/./bin/dsymutil.exe --llvm-tools-dir C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/./bin --lldb-obj-root C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/tools/lldb --lldb-libs-dir C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/./lib --skip-category=watchpoint C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\tools\lldb-server -p TestGdbRemoteLaunch.py
--
Exit Code: 1

Command Output (stdout):
--
lldb version 19.0.0git (https://github.com/llvm/llvm-project.git revision b298e2d2d2251767a5ddcdef2310494d3b8da773)
  clang revision b298e2d2d2251767a5ddcdef2310494d3b8da773
  llvm revision b298e2d2d2251767a5ddcdef2310494d3b8da773
Skipping the following test categories: ['watchpoint', 'libc++', 'libstdcxx', 'dwo', 'dsym', 'gmodules', 'debugserver', 'objc', 'fork', 'pexpect']


--
Command Output (stderr):
--
UNSUPPORTED: LLDB (C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe-aarch64) :: test_QEnvironmentHexEncoded_llgs (TestGdbRemoteLaunch.GdbRemoteLaunchTestCase.test_QEnvironmentHexEncoded_llgs) (skip on windows) 

UNSUPPORTED: LLDB (C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe-aarch64) :: test_QEnvironment_llgs (TestGdbRemoteLaunch.GdbRemoteLaunchTestCase.test_QEnvironment_llgs) (skip on windows) 

PASS: LLDB (C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe-aarch64) :: test_launch_failure_via_vRun_llgs (TestGdbRemoteLaunch.GdbRemoteLaunchTestCase.test_launch_failure_via_vRun_llgs)

UNSUPPORTED: LLDB (C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe-aarch64) :: test_launch_via_A_llgs (TestGdbRemoteLaunch.GdbRemoteLaunchTestCase.test_launch_via_A_llgs) (skip on windows) 

UNSUPPORTED: LLDB (C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe-aarch64) :: test_launch_via_vRun_llgs (TestGdbRemoteLaunch.GdbRemoteLaunchTestCase.test_launch_via_vRun_llgs) (skip on windows) 

FAIL: LLDB (C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe-aarch64) :: test_launch_via_vRun_no_args_llgs (TestGdbRemoteLaunch.GdbRemoteLaunchTestCase.test_launch_via_vRun_no_args_llgs)

======================================================================

FAIL: test_launch_via_vRun_no_args_llgs (TestGdbRemoteLaunch.GdbRemoteLaunchTestCase.test_launch_via_vRun_no_args_llgs)

----------------------------------------------------------------------

Traceback (most recent call last):


kbluck pushed a commit to kbluck/llvm-project that referenced this pull request Jul 6, 2024
…lvm#97698)

0f9fbbb changed the version printouts.
This broke linker detection in Meson, when disambiguating between the
ld.lld and lld-link interfaces, in

https://github.com/mesonbuild/meson/blob/1.4.1/mesonbuild/linkers/detect.py#L67,
which checks for the string "(compatible with GNU linkers)" including
the parentheses.

Reinstate the parentheses in the printout here, for compatibility with
Meson. The printout looks a little odd in this form, "LLD 19.0.0
(https://github.com/llvm/llvm-project
173514d) (compatible with GNU
linkers)", but works with Meson.

The Meson check is loosened in mesonbuild/meson#13383,
but existing versions of Meson with the too strict check will be around
for quite some time, so we should only change LLD to the new form once
older versions of Meson aren't used for these targets any longer, i.e.
earliest within a few years.
eli-schwartz pushed a commit to mesonbuild/meson that referenced this pull request Jul 10, 2024
Don't require the string to be enclosed in parentheses.
llvm/llvm-project#97323 changed the LLD
version printout to no longer be enclosed in parentheses, which
made Meson fail to detect the linker style used here.

The LLD change is being reverted in
llvm/llvm-project#97698 in order to fix
building with existing Meson versions, but for the future, loosen
the check slightly, to not require the parentheses.

(cherry picked from commit 1ca002a)
Volker-Weissmann pushed a commit to Volker-Weissmann/meson that referenced this pull request May 1, 2025
Don't require the string to be enclosed in parentheses.
llvm/llvm-project#97323 changed the LLD
version printout to no longer be enclosed in parentheses, which
made Meson fail to detect the linker style used here.

The LLD change is being reverted in
llvm/llvm-project#97698 in order to fix
building with existing Meson versions, but for the future, loosen
the check slightly, to not require the parentheses.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants