"error: LLDReportedFailure" while attempting to "zig build-exe hello.zig" on a RAMDrive on Win10

[OscarL]

Using zig-windows-x86_64-0.8.0-dev.2749+167754b31.zip on Win 10 1909.

Was testing that -dev version due to #8995.

With R: being a RAMDrive created with ImDisk, I got the following:

R:\zig-windows-x86_64-0.8.0-dev.2749+167754b31 > zig run hello.zig
Hello, world!

R:\zig-windows-x86_64-0.8.0-dev.2749+167754b31 >

R:\zig-windows-x86_64-0.8.0-dev.2749+167754b31 > zig build-exe hello.zig
lld-link: error: cannot open output file hello.exe: function not supported
error: LLDReportedFailure

R:\zig-windows-x86_64-0.8.0-dev.2749+167754b31 >

Suspecting the issue lies on RAMDrive incompatibility... moved the zig folder to a regular HDD, and there the build-exe was successful.

I've seen similar bugs related to RAMDrives on other languages/programs, for example, this bug in Python (a comment there mentions "The above-mentioned cases are all due to WINAPI CreateFileW failing").

Might be a too-niche use case, but... being able to run/build things from RAM helps a lot on older processors / slow HDDs.

In any case, I thought it is always better report this kind of things, right?

[EDIT]; Noticed that after each failed zig build-exe hello.zig invocation, a new empty file named hello.exe.tmpb9d9e3c appears in the current directory (last portion of the filename varies each time).

[andrewrk]

Can you look into this? What function is being called that is not supported? Why doesn't a ram drive support that function?

[OscarL]

@andrewrk: I'll do my best, and report back if I find anything more specific, although I have to stress this: I'll surely prove myself to be not skilled enough. Just a a self-taught tinkerer here.

My real "talent" is in finding ways of breaking things even when not trying to (that's why I worked in QA automation before "retiring", and why I tend to report any weird case I find in open source projects).

[andrewrk]

Thanks for the report. At this stage in the development of zig, issues like this tend to be pretty low priority since things like finishing the self-hosted compiler, or building the package manager, are pivotal to the success of the project, and will generate hundreds of bugs to solve.

However I would say that in the release cycle leading up to 1.0 - which is still a couple years away - people like you filing bugs like this will be quite valuable indeed.

[OscarL]

[EDIT:] I've rewritten this comment several times, this last time to avoid pointing to unrelated info, and clarify (hopefully) what the issue seems to be about.

Someone using the LDC compiler ran into the same issue with lld-link and RAM drives: ldc-developers/ldc#3675

Albeit it's title mentions "permission denied" as the error in that issue, a further comment/update reports the function not supported error from lld-link while using a RAM Drive (while using a different RAM driver than the one used by me).

For me, that issue got prematurely closed.

I too experience the creation of empty files named hello.exe.tmpb9d9e3c (for example, it changes everytime). Didn't noticed that before.

That "tmp" in the empty file names might point in the right direction (temp file usage failing in LLD-LINK, should narrow it a bit).

Anyway, the issue is clearly with lld-link.exe when using RAM drives/disks, and clearly not a bug in Zig.

I'll close this issue, and take it to LLVM devs.

[andrewrk]

Anyway, the issue is clearly with lld-link.exe when using RAM drives/disks, and clearly not a bug in Zig.

I'll close this issue, and take it to LLVM devs.

Thanks - however in this project we do leave issues open to track bugs in dependencies. Bugs in dependencies are Zig's bugs too! We either need to work with upstream to solve the bug, or don't depend on it.

[schellingb]

Sorry to post here but searching the web for "cannot open output file" "function not supported" leads to this issue and not many others.
@OscarL Did you end up reporting this to LLVM? I searched on the llvm bugzilla but didn't find anything. I noticed the issue starts with LLVM 11.0.1-rc2 (released Dec 19, 2020), while it was fine on 11.0.1-rc1 (released Nov 26, 2020).

[OscarL]

@schellingb: shame on me... I did not ended up reporting it to LLVM. Between life complications, and the convoluted process needed to file a simple report... I got discouraged (Low barrier to entry for bug reports is a must in any project).

Nice work on bisecting the problematic LLVM version!

Maybe you can do the honors and file the issue on LLVM? (I'm assuming you hit my same bug, and have both a fresher memory, and even more data than I did (LLVM versions/dates).

If you do, please link that issue back here. If you do not, poke me one more time and I'll do my best :-)