llvm-ar fails to handle long paths on Windows

[bgamari]

It appears that llvm-ar.exe (version 13.0.1) fails to accept long paths on Windows. For instance, clang can output to a long path without any trouble:

#!/usr/bin/env python
from pathlib import Path
tmp = Path('/'.join('a'*32 for j in range(16)))
tmp.mkdir(True, True)
Path('hi.c').write_text('int main() { return 0; }')

import subprocess
subprocess.run(['clang', '-o', tmp / 'out.o', 'hi.c'])

whereas asking ar to write an archive to a long path fails:

#!/usr/bin/env python
from pathlib import Path
tmp = Path('/'.join('a'*32 for j in range(16)))
tmp.mkdir(True, True)
Path('hi.c').write_text('int main() { return 0; }')

import subprocess
subprocess.run(['llvm-ar', 'rc', tmp / 'out.a', 'hi.c'])

$ python test.py
Traceback (most recent call last):
  File "C:\msys64\home\ben\ghc-2\test2.py", line 4, in <module>
    tmp.mkdir(True, True)
  File "C:/msys64/mingw64/lib/python3.9/pathlib.py", line 1325, in mkdir
    self._accessor.mkdir(self, mode)
FileExistsError: [WinError 183] Cannot create a file when that file already exists: 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'

[llvmbot]

@llvm/issue-subscribers-tools-llvm-ar-llvm-ranlib

[bgamari]

It appears that long paths are also not handled for input paths.

[RyanGlScott]

@bgamari, do the test scripts in #54559 (comment) actually demonstrate the bug? If I use the second, llvm-ar-based script, then it succeeds without any issues (using llvm-ar-14.0.6). I think the Cannot create a file when that file already exists error occurs if you run the script a second time after out.a has been created, which seems be an issue with Python's pathlib rather than anything to do with llvm-ar.

[RyanGlScott]

Ah, hold on. It appears that the version of LLVM that I'm using has something to do with it. First, let me alter the script a bit:

#!/usr/bin/env python
from pathlib import Path
tmp = Path('/'.join('a'*32 for j in range(16)))
if not tmp.exists():
    tmp.mkdir(True, True)
Path('hi.c').write_text('int main() { return 0; }')

import subprocess
subprocess.run(['llvm-ar', '--version'], shell=True)
res = subprocess.run(['llvm-ar', 'rc', tmp / 'out.a', 'hi.c'], shell=True)
if res.returncode == 0:
    print('llvm-ar successfully used a long path')

I've changed this such that:

• pathlib's mkdir is only called if the long directory doesn't exist, which avoids any pathlib-specific oddities
• subprocess.run() is invoked with shell=True, which allows changing what version of llvm-ar is picked up on the PATH

If I run this script with llvm-ar-13.0.0, then I observe a long-path-related issue:

$ PATH=/c/ghcup/ghc/9.4.1/mingw/bin:$PATH python test.py
LLVM (http://llvm.org/):
  LLVM version 13.0.0
  Optimized build.
  Default target: x86_64-w64-windows-gnu
  Host CPU: znver2
llvm-ar.exe: error: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/out.a: No such file or directory

On the other hand, if I use llvm-ar-14.0.6, then there is no issue:

$ python test.py
LLVM (http://llvm.org/):
  LLVM version 14.0.6
  Optimized build.
  Default target: x86_64-w64-windows-gnu
  Host CPU: znver2
llvm-ar successfully used a long path

So perhaps this issue has been fixed already?

[bgamari]

Oh dear, good catch @RyanGlScott !

Good news that this is already fixed.

[oltolm]

Can this be closed?