LLVM Bugzilla is read-only and represents the historical archive of all LLVM issues filled before November 26, 2021. Use github to submit LLVM bugs

Bug 42623 - lld-link.exe fails to build on a Windows networked drive running under Parallels VM / LLVM ERROR: IO failure on output stream: bad file descriptor
Summary: lld-link.exe fails to build on a Windows networked drive running under Parall...
Status: NEW
Alias: None
Product: lld
Classification: Unclassified
Component: COFF (show other bugs)
Version: unspecified
Hardware: Macintosh All
: P normal
Assignee: Unassigned LLVM Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-07-15 06:19 PDT by Robert M. Münch
Modified: 2021-03-04 00:41 PST (History)
4 users (show)

See Also:
Fixed By Commit(s):


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Robert M. Münch 2019-07-15 06:19:19 PDT
I have a program that builds with no errors or warnings on a Windows-10 system internal drive (C:) that runs in a Parallels VM on OSX.

The same program won't build if the project files are on a Parallels shared drive, which is mapped into Windows as a network drive.

The error is: LLVM ERROR: IO failure on output stream: bad file descriptor

There seems to be a related problem from the Rust community: https://github.com/rust-lang/rust/issues/54216
Comment 1 Reid Kleckner 2019-07-15 11:26:56 PDT
I believe this error often arises when the file descriptor limit is reached. It's plausible that network drives have lower descriptor limits.

LLD's current normal file I/O pattern looks like this:
- for all inputs:
  - open fd
  - memory map file from fd
  - close fd
... work
- open temp output fd for write
- calculate output file size, reserve bytes
- memory map output file
- ... write bytes in place
- commit the temp file by renaming it and closing fds

However, the text of the error message comes from raw_fd_ostream, which is not used for normal output writing in LLD. Are you using LTO or some other feature? LLD seems to only use output streams for auxiliary files like XML manifests and LTO blobs.
Comment 2 Robert M. Münch 2019-10-02 10:35:31 PDT
Sorry for the late answer.

I don't think I'm using anything special. Here is the linker command line:

'C:\Program Files (x86)\LLVM\bin\lld-link.exe'  /dll /def:dll.def /libpath:../../../libs /libpath:'C:\Program Files (x86)\IntelSWTools\compilers_and_libraries\windows\compiler\lib\ia32' /libpath:'C:\Program Files (x86)\LLVM\lib\clang\8.0.0\lib\windows' /nodefaultlib:libcmt.lib /nodefaultlib:libcpmt.lib /out:c:\tmp\\video-player.dll ../src/main.o ../src/player.o kernel32.lib user32.lib gdi32.lib ole32.lib msvcrt.lib mf.lib mfplat.lib mfuuid.lib strmiids.lib

But I'm going to link Parallels Support to this ticket. Maybe that helps them too.
Comment 3 Robert M. Münch 2019-10-02 10:39:48 PDT
One more note: Using MSVC or the Intel C++ compiler instead of LLVM, everything works.
Comment 4 Sam Clegg 2021-03-03 06:59:35 PST
We have emscripten users reporting the similar issues with wasm-ld that I suspect is related to VM usage:

https://github.com/emscripten-core/emsdk/issues/686
https://github.com/emscripten-core/emsdk/issues/677