Building debug on Windows fails because it looks for release libjulia.dll

[cmundi]

make debug fails because line 76 of the top-level Makefile is used for both debug and release but attempts to always link with the release build of libjulia.dll. editing that line, I was able to build debug. The julia Makefile is just subtle enough that I'm not going to try to fix this just yet. :)

[tkelman]

Can confirm. Had noticed that too, easy solution is make release before you make debug. I suspect that line pulls in -ljulia only on Windows because dll's can't have undefined references.

So, question to @vtjnash or others more knowledgeable than me: should sys.dll always link against libjulia.dll, or is linking against libjulia-debug.dll okay if the user happens to build debug first? If it's the former, then debug should depend on release. Maybe just on Windows, if there's any reason not to do it everywhere?

[vtjnash]

We only make one sys.dll, might be good to make two on windows and update dump.c to choose the right one

[tkelman]

Would that require two passes through the whole julia --build, llc process to make two of sys.bc and/or sys0.bc? I ask because building the system image is taking a significant fraction of the build time in my AppVeyor setup, and I'm having odd test failures with the release executable but not debug (see #6109 (comment))

[vtjnash]

Only the dll is needed twice (you might even be able to just do a binary edit to replace the dll name). But the .bc/.o/.dll are also optional and it can be good to delete it to find strage errors (such as we can't catch asynch math and stack overflow errors in sys.dll)

[cmundi]

I was just about to suggest a patch to the Makefile, but now that I've read the comments on this issue its clear that my approach is not general enough. My thoughts are similar to @tkelman - it's helpful to have a well-defined "manifest" for every build config. Otherwise, significant time can be spent chasing down bugs which appear only in debug or only in release. For me at least, this isn't about "getting it to build" -- that's easy. For me it's about traceability.

[vtjnash]

"getting it to build" -- that's easy

haha

Actually, it might be a good idea to link two dll files. Deleting the sys.dll is often a good debugging solution too. Because of the negative impact to error handling and backtraces (you can't catch errors or create backtraces from the function in there), I'm also strongly considering removing the sys.dll file altogether

[ihnorton]

Fixed by #12151.