Linker runs into Windows 260 character path limit

[ignas2]

Description

When clang++ invokes linker it adds include paths like this one (can be seen with -v option):

-Lartifacts/Stevedore/android-ndk-win/toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64/lib/gcc/arm-linux-androideabi/4.9.x/../../../../arm-linux-androideabi/lib/../lib/armv7-a

Notice all the ../ parts. This makes the path unnecessarily long and Windows runs into 260 character limit for paths making linker fail. To reproduce the issue NDK needs to be placed in a directory that has a long name (so that the total global path would exceed 260 characters). Please normalize the path before passing it to the linker. Or even better add a long path support to the linker itself.

Environment Details

• NDK Version: 18.1.5063045
• Build system: Custom
• Host OS: Windows
• Compiler: Clang
• ABI: armv7-a
• STL: libc++
• NDK API level: 16
• Device API level: NA

[enh]

which linker?

i know @pirama-arumuga-nainar fixed clang++ itself in #478 but we haven't touched (and won't touch) the binutils. i'm assuming lld already works (except for the fact that the r18 lld hangs for you)? we released r19beta1 yesterday afternoon but haven't had time yet to see whether it works with your linker hang test case...

[Zingam]

@ignas2 Will subst help?

[pirama-arumuga-nainar]

IIUC, Clang normalizes the paths before invoking the linker. But as mentioned in #478 long path support still needs to be enabled before it can be useful.

@ignas2 Can you confirm if you're enabling this? If so, I'll try to reproduce this myself.

[ignas2]

Yes, I have enabled long paths via Group Policy, restarted machine and that did not help. Like I've said in the first post I'm passing -v to clang++ and that displays arguments that are passed to the linker. The paths are not normalized. Also I'm using default (Gold) linker in this case.

[pirama-arumuga-nainar]

I'm wary of making Clang change what it passes to the linker. It may work for the version of binutils we have but may break other setups that use a different version or linker (where the linker was doing specific processing of its input that's agnostic of the long paths).

Having the linker handle long paths may be the best bet.

[halx99]

Update: recently, I improve the wsLongPaths patch and update to v3.4, now the patch support all of ndk:
support os: win7/win10
support ndk: r14b~r21d (x64)
support build system: ndk-build, cmake
https://github.com/simdsoft/wsLongPaths/releases

[rectified95]

Pinging this issue - can we add long path support to the linker?

[DanAlbert]

No longer necessary since it works with LLD and binutils linkers are gone in r23.