Random Link/Build Errors When Building In-Editor

Hey there- I'm not sure if my problem is a result of my own incompetence or not...

I'm building on Windows using MSVC. When I build in-editor I get random linking errors that sometimes prevents a build from completing successfully. An example is:

1
LINK : fatal error LNK1104: cannot open file 'win32_main.obj'


I'm just using a HMH-style batch file, located in the source code's parent directory, to build, which can be found here. The same linking errors don't appear to happen when I build from the terminal. It should be said that the builds in-editor sometimes work, and restarting 4coder usually fixes it.

Apologies in advance if this is an oversight on my part; I think it might be because I don't know how to properly write batch files... Thanks for the help!

Edited by Ryan Fleury on
It may be that there is actually a bug in the script *technically* but the terminal fixes it by forcing things to happen in more strict orders or something... not sure. Are you running this batch script from a fixed command set in a project file, or with <alt M> ?
Hmm, interesting... I'm just using Alt+M currently.
Ahh okay. In that case, the other thing to keep in mind is what the current directory is for the script. I can't remember the rules of <alt m> but it may be that which file you have actives effecting that. Setting up a project lets you fix the root directory so that it's no longer searching for and deducing the build script based on the active file.
Hm, okay- I'll try that out. I'm not sure if that is what was causing the errors, though, as at the time, all of the code was in the same directory. What's interesting is that it is a seemingly rare phenomenon now...
Hmmm... interesting. It could also be that with <alt m> you're launching the same process multiple times and somehow one of them never gets freed until 4coder closes... ? That could explain why the specific error you hit involves failure to open an intermediate file.

You could try spamming <alt m> quickly and seeing if that increases the chances of creating the problem?

Also, 4coder internally supports a few different ways of handling the situation when multiple child processes appear to be in conflict, including launching the new one, and showing it in place of the old, and refusing to launch a new one while a parallel instance appears to be running. It might be that the "build search" <alt m> and "project command" <alt Fkey> don't use the same behavior... I can't remember right now.

EDIT: Just had a look at the code, it looks like they both do the overlap with conflict option, so scratch out that theory.

Edited by Allen Webster on
Hmm, yeah, it doesn't seem like spamming it really changes the likelihood. It's relatively rare, so it's not a major issue; I still need to find some time to try out a project file instead though (there are some features in project files that seem valuable to use anyways)...
I set up a project file, and everything is working nicely, though the problem still seems to persist at seemingly random times, interestingly enough. It is a fairly rare occurrence, but I did experience it a couple times after setting up the project.
Hmm well this is a real puzzler. Thanks for helping me eliminate possible causes.

Unfortunately I don't have any more ideas on this right now. It seems like it must be something about the timing of events and how they work out differently on the command line than in 4coder. It is as if the linker is running before the compiler finishes but I have no idea why that would even happen...
Update!

I think I have a new idea, can you answer these questions for me? (Sorry if you already mentioned them, rushing a bit this morning).

Operating system version?
Visual studio version?
Great! No worries, I hadn't mentioned those. :)

I'm currently at my work computer which also had the issue, but I'll come back and update this post later with my home computer details as well. The two setups are similar, but might vary slightly (on particularly the operating system version).

Operating System Version: Windows 10.0.14393
Visual Studio Version: Community, 14.0 (2015)

Hopefully that's specific enough- let me know if there are any version details I'm missing that you need.
I think I hit the same bug this morning with Windows 10, Visual Studio 2017. I also run a Windows 10 with 2015 that doesn't get the issue though... so it's not necessarily related to that after all... hmm.

Well the good news is I think I have a repro case anyway, I'll let you know if I have more.
Hmm, okay. Thanks so much for your responsiveness and help!