search

ziglang / zig

General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.
https://ziglang.org
MIT License
34.83k stars 2.55k forks source link

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

Open OscarL opened 3 years ago

OscarL commented 3 years ago

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 commented 3 years ago

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

OscarL commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

[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: https://github.com/ldc-developers/ldc/issues/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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 :-)

schellingb commented 3 years ago

@OscarL No problem! Luckily I went through the convoluted process before when I encountered a higher priority code generation problem in clang. I totally agree that bugzilla is not fun to sign up or use...

Anyway here's the bug I just opened on the LLVM bugzilla: https://bugs.llvm.org/show_bug.cgi?id=52080

Hopefully this can get fixed, big fan of using RAM disks here :-)

OscarL commented 3 years ago

I've just read your bug report. Outstanding work @schellingb! Only thing missing is a link-back to this issue :-) (just for reference)

Let us hope it gets fixed upstream... and allow me the time to mention the really cool attitude @andrewrk had regarding this issue! (How I wish all my interactions with software developers were like this!).

Somehow I believe that if @andrewrk "MO" keeps being this way... Zig has a BRIGHT future ahead (besides its technical advantages!)

OscarL commented 2 years ago

Still happens with 0.10.0-dev.1908 at least.

Placing the zig cache on an ImDisk RAM drive produces a different set of errors (but seems to have the same root cause):

LLVM Emit Object... error(mingw): unable to turn kernel32.def into kernel32.lib
error(mingw): unable to turn ntdll.def into ntdll.lib
error(mingw): unable to turn advapi32.def into advapi32.lib
error: unable to build compiler_rt: UnableToWriteArchive
error: unable to build libssp: UnableToWriteArchive
error: unable to build zig's multitarget libc: UnableToWriteArchive
error: unable to generate DLL import .lib file: WritingImportLibFailed

@schellingb, and for any other passerby searching for info about this:

WORKAROUND:

The issue disappears if one switches from ImDisk to the newer tool (AIM, by the same author) as the tool/driver that creates the RAM drive.

Apparently the former emulates disk PARTITIONS, while the latter emulates complete DISKS, making the newer one more compatible (seems about right). Bad for me, as I find ImDisk much more convenient to use.

Even keeping %TEMP% in an ImDisk created RAMDrive, while having the zig cache AND the test project in one created with AIM works with no problems.

Still a bit puzzling that zig build-exe fails, but calling zig run src\main.zig works, but... oh well... now at least there's a workaround while we wait for fixes upstream.

schellingb commented 1 year ago

Hey there, I'm a bit late but on the LLVM side this has been fixed for me since LLVM 14 (and llvm/llvm-project#51422 was closed). I'm not sure what the zig build tools are based on, but if it's LLVM 14 or newer I think this could get closed as well.