Hi Arun, thanks for taking the time to dig into this! On Thu, Jul 13, 2017 at 3:29 AM, arun.s <[email protected]> wrote: > Thanks to Kalrish i can now build tup in windows with mingw toolchain. I > debugged this problem further and sure enough it is the chdir and getcwd > calls that are the source of problems.
I've started to merge Kalrish's patches. Hopefully we can finish that work soon to make it easier to test on Windows. > From msdn (i presume chdir internally calls SetCurrentDirectory): > >> Multithreaded applications and shared library code should not use the >> GetCurrentDirectory function and should avoid using relative path names. The >> current directory state written by the SetCurrentDirectory function is >> stored as a global variable in each process, therefore multithreaded >> applications cannot reliably use this value without possible data corruption >> from other threads that may also be reading or setting this value. This >> limitation also applies to the SetCurrentDirectoryand GetFullPathName >> functions. The exception being when the application is guaranteed to be >> running in a single thread, for example parsing file names from the command >> line argument string in the main thread prior to creating any additional >> threads. Using relative path names in multithreaded applications or shared >> library code can yield unpredictable results and is not supported. > > > I have a fix that removes calls to fchdir or chdir (except in initial scan) > in tup source code, passing around absolute paths only, to get rid of these > aborts in windows. There are other minor changes as well. > > http://www.github.com/svark/tup is forked off kalrish's repo. Would you want to file a pull request for your fix? >> I keep running into these two errors when running tup on windows in multi >> threaded mode. >> >> >tup error: Unable to open directory for update work. >> >> >> >chdir: No such file or directory >> >tup error: Failed to fchdir in a compat wrapper function. >> >> I use tup v0.7.3-60-gd3bfa7c but I have encountered this in v0.7.5. >> I use 0.7.3.* because it allows me to ignore PDB files. >> >> Has anyone else encountered these. It is difficult to reproduce this. But >> i face this very often to be frustrated by them. >> More the threads more the chances of these aborts. Does anyone know of any >> workarounds? I've run several test cases in thousands of loops on Windows and haven't hit these errors. Any idea what I would need to do to trigger it? Does it only happen with specific types of rules? I have hit a different one, though: .tup/tmp/output-121: Broken pipe tup error: Unable to open sub-process output file after the process completed. *** Command ID=121 failed: gcc -c foo.c -o outdir33\foo.o Have you seen this one? -Mike -- -- tup-users mailing list email: [email protected] unsubscribe: [email protected] options: http://groups.google.com/group/tup-users?hl=en --- You received this message because you are subscribed to the Google Groups "tup-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
