Tup is terrribly broken on Windows

[Dragoon]

My attempts with trying to use tup on Windows have been hopeless as of now.
Not even 32bit builds work, gcc ends up segfaulting.

Currently we function by injecting a dll into the application and hooking the file functions to ensure dependencies are correct.
Now is there another way? If not, might we perhaps get better results when using a library such as Deviare-Inproc or EasyHook?

Tup is my preferred build system, because of its speed and correctness, not having to worry about my builds being incorrect has been a great experience on linux.
However I cannot continue to use tup if tup doesn't work on Windows.
Thus I would love it if we could work towards a better solution to support windows.

I'm not sure what FUSE is being used for, but if FUSE is used for dependency checking, perhaps something like Dokany (https://github.com/dokan-dev/dokany) is an option?
I don't know what people think about installing drivers for a build system, but if that's what it takes, it's something I'm willing to do.

[Freddie Chopin]

On środa, 30 grudnia 2015 17:07:26 CET Dragoon wrote:
> My attempts with trying to use tup on Windows have been hopeless as of now.
> Not even 32bit builds work, gcc ends up segfaulting.

You must be more specific - I've tried tup on Windows a few days ago and the
most recent development version indeed has an important bug, but it actually
works correctly (see https://github.com/gittup/tup/issues/255 ). Apart from
that problem and a slight problem with 64-bit tools (see https://github.com/
gittup/tup/issues/256 ) tup works as expected, just as it always worked...

So "it works here"...

Regards,
FCh

[Dragoon]

Okay, so this is my machine.
Windows 7 Ultimate 64 bit with Japanese locale, only important updates installed.

My tool chain is MSYS2, I tried both 64 bit gcc and 32 bit (i686) gcc, tup is the latest build found at the tup website.
I made a simple Tupfile with the following rules

:main.cpp |> g++.exe -c main.cpp -o main.exe |> main.exe

When I execute it from a 64 bit shell, thus using 64 bit gcc, I get the following error:
tup error: failed to inject dll: No such file or directory
When I execute it from a 32 bit shell, thus using i686 gcc, I get these errors:
* 100% 1) g++.exe -c main.cpp -o main.exe
 *** tup errors ***
 *** Command ID=24 failed with return value -1073741819
tup error: Expected to write to file 'main.exe' from cmd 24 but didn't
 *** Additionally, command 24 failed to process input dependencies. These should probably be fixed before addressing the command failure.

So this makes tup completely unusable for me on Windows, perhaps I could compile the latest development branch for windows?

Regards,
Dragoon

[Freddie Chopin]

Hello again!

A very important question first - are you trying to run tup _FROM_ the msys
shell? Have you tried running tup using regular command line prompt for
Windows (cmd)? Just add executables from msys to your system's PATH (they are
located in "<installation path>\usr\bin") and you can use them without msys
shell.

Regards,
FCh

[Dragoon]

Hi again.

I tried running tup from both the MSYS shell and from cmd.
MSYS shell gives me those errors as I described earlier and cmd shell gives me garbled output.
Running tup from either shell outputs no executable.

Best regards,
Dragoon

[Freddie Chopin]

On środa, 6 stycznia 2016 04:22:00 CET Dragoon wrote:
> cmd shell gives me garbled output.

This is exactly the same problem as I linked in my first post - https://
github.com/gittup/tup/issues/255 . Mike has already fixed that, but I haven't
checked it yet. Either try the most recent development version or try the one
with "...-104-..." in the name.

Regards,
FCh

[Freddie Chopin]

On środa, 6 stycznia 2016 14:31:11 CET you wrote:
> Either try the most recent development version or
> try the one with "...-104-..." in the name.

Small correction - the fix is not yet available in any of the builds, so just
try this one - tup-v0.7.3-104-g65fdf0f.zip

http://gittup.org/tup/win32/

Regards,
FCh

[Mike Shal]

There is a newer version with the garbled output fix: http://gittup.org/tup/win32/tup-v0.7.3-125-g40202e8.zip

On my Windows 7 64bit VM, I can run gcc and cl both from a cygwin shell and the cmd shell. Do you still have the errors about injecting the DLL with this version?

-Mike

[Dragoon]

Yes, I'm still getting errors that it can't inject the dll when using 64 bit gcc, both from the MSYS2 64 bit shell and cmd shell.
The 32 bit gcc crashes using the process has stopped working window when I run it from the CMD shell, but silently crashes from the MSYS2 32 bit shell.
Both cmd and the 32 bit MSYS2 shell have gcc crash with this return value: -1073741819 (0xC0000005) indicating it segfaulted.

Consider trying out MSYS2 http://sourceforge.net/p/msys2/wiki/MSYS2%20installation/ for your tests.

Alternatively I could upload the official trial ISO of Windows 7 Ultimate 64 bit for you to try out tup on.

- Dragoon

[Freddie Chopin]

Hello!

I cannot reproduce this issue... In 32-bit shell:

> MINGW32 ~/tup
> $ tup
> [ tup ] [0.016s] Scanning filesystem...
> [ tup ] [0.016s] Reading in new environment variables...
> [ tup ] [0.031s] Parsing Tupfiles...
>
> 100% 1) [0.000s] .
>
> [ tup ] [0.031s] No files to delete.
> [ tup ] [0.031s] Generating .gitignore files...
> [ tup ] [0.031s] Executing Commands...
>
> 100% 1) [0.047s] g++.exe -c main.cpp -o main.exe
>
> [ tup ] [0.093s] Updated.

In 64-bit shell:

> MINGW64 ~/tup
>
> $ tup
> [ tup ] [0.011s] Scanning filesystem...
> [ tup ] [0.011s] Reading in new environment variables...
> [ tup ] [0.011s] Parsing Tupfiles...
>
> 100% 1) [0.000s] .
>
> [ tup ] [0.021s] No files to delete.
> [ tup ] [0.021s] Generating .gitignore files...
> [ tup ] [0.021s] Executing Commands...
>
> 100% 1) [0.032s] g++.exe -c main.cpp -o main.exe
>
> [ tup ] [0.064s] Updated.

I'm also doing this on virtual machine with Windows 7 64-bit, but I'm pretty
sure that on "real" Windows 7 it would work the same.

Regards,
FCh

[Dragoon]

It is rather unfortunate that our results differ, I think this may be differences between Windows editions.
Either way, as it stands now, tup is currently unusable for me on Windows and I personally would rather not switch to another build system, as most build systems don't satisfy my requirements.

- Dragoon

[Freddie Chopin]

On pon, 2016-01-18 at 18:33 -0800, Dragoon wrote:
> It is rather unfortunate that our results differ, I think this may be
> differences between Windows editions.

Then you have to find what's different on your side - no one has ever
reported such problems... Have you tried on different PC? You can
always install Virtual Box with any Windows version (Microsoft gives
free Virtual Box images - google for them) and try there. You can try
with any other executable, different than gcc - for example you can try
copying files with cp, using echo or cat.

Regards,
FCh

[Dragoon]

Okay, I tested from different terminal emulators today, with the 0.7.4 tag I built in virtual box.
This also looked like to be broken, but once I started an msys2 shell, it worked.
Looks like ConEmu ended up interfering with the injection that tup was doing.
So I guess I owe you guys an apology for wasting your time, sorry for that.

It might be worthwhile to put a warning on the website that using a terminal emulator such as ConEmu could cause issues with tup, to prevent this discussion from happening again.

Best regards,
Dragoon