Comment by meinersbur | Hacker News Reader

Comment by meinersbur | Hacker News Reader

Parent Full thread

They are identical copies of each other. Since symlink support is not universal on Windows (Possible since around the time WSL was introduced, but still requires either special privileges or developer mode enabled), many tools including GNU autotools fall back to copying. Since recently (https://reviews.llvm.org/D99170), LLVM et least tries to create a symlink on Windows, but still caused problems because this is kind of unexpected by Windows. The NSIS installer used by the official Windows installer (https://llvm.org/builds/) does not support symlinks at all such that the installer includes 4 identical copies of Clang.

A clean solution would be to have stub executables that link to a central libClang.dll/libLLVM.dll (-DCLANG_LINK_CLANG_DYLIB=ON), but this is not supported under Windows because a DLL can export at most 2^16 symbols. Some work would need to be invested to make process launching on Windows work differently than on other platforms, but then disk space is not that much of a problem.

The Clangs are different from each other in some installations, and identical in others. In particular the Visual Studio installation doesn't have identical binaries, but the MSYS2 installation does. You'll have to check yours. For example, if you dir "%ProgramFiles%\Microsoft Visual Studio\2022\Community\VC\Tools\Llvm\bin\clang*.exe" you'll see they're slightly different sizes.

(Also note that in this case you don't need symlinks per se, just identical binaries with hardlinks. Each executable could inspect argv[0] and figure out what it's invoked as, and behave accordingly.)

What I don't understand is why can't they just bundle everything into a single DLL, then make whatever stub executables they want just call the exported main() in that DLL. I think that might be what MSYS2's copy already does, though I haven't checked. That DLL wouldn't need to export anything else, just the main() function that each .exe stub would forward to. And it can handle everything else internally if it so desires.

Different sizes doesn't always mean different sizes (I'm not sure if that is completely true using 'dir'): https://superuser.com/questions/1353064/why-does-size-on-dis...

I'm well aware of all the nuances but I assure you the files are different here.

> Since symlink support is not universal on Windows (Possible since around the time WSL was introduced, but still requires either special privileges or developer mode enabled)

Symlinks have been supported since Vista, though by default creating a symlink does indeed require Admin rights. Hardlinks can be created by anybody and are extensively used by Windows itself.

> Symlinks have been supported since Vista

I'm not aware of even Windows 10 or Windows 11 being able to create Symlinks on FAT32 and exFAT, but I could be wrong? But it doesn't matter, the code as written is cross platform, it works on Apple Journaled File Systems, APFS, exFAT, etc. We then compile it for Macintosh, compile it for Windows, and compile it for Linux.

We can then spend extra time and carefully detect each filesystem and each platform and then make the optimization if we can. And this is a valid criticism that we have not done this yet. But no matter what we need this general code that will always work FIRST, what the links are is a space optimization to save valuable SSD space when it is possible.

Reply on news.ycombinator.com