• Andrei Alexandrescu (9/9) Oct 28 2017 I am using wine to build our Windows toolchain on Linux per
• Dmitry Olshansky (6/16) Oct 28 2017 Wine is not particularly stable emulation software when it comes
• Jonathan M Davis (24/42) Oct 28 2017 Depending on what you're doing, wine can work, but it's not trustworthy ...
• Kagamin (4/13) Oct 30 2017 That test is incorrect, see:

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

I am using wine to build our Windows toolchain on Linux per 
https://wiki.dlang.org/Building_under_Posix. After building dmd, I tried 
to unittest druntime:

wine make -f win32.mak

and got this:

core.exception.AssertError src\core\sync\mutex.d(380): unittest failure

Is this reproducible? Does anyone have an attack on this?


Thanks,

Andrei

Dmitry Olshansky <dmitry.olsh gmail.com> writes:

On Saturday, 28 October 2017 at 18:58:50 UTC, Andrei Alexandrescu 
wrote:
 I am using wine to build our Windows toolchain on Linux per 
 https://wiki.dlang.org/Building_under_Posix. After building 
 dmd, I tried to unittest druntime:

 wine make -f win32.mak

 and got this:

 core.exception.AssertError src\core\sync\mutex.d(380): unittest 
 failure

 Is this reproducible? Does anyone have an attack on this?

Wine is not particularly stable emulation software when it comes 
to testing Windows.

I’d recommend using Windows evaluation for server in a virtual 
machine. 180 days for free + prolongation.

 Thanks,

 Andrei

Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:

On Saturday, October 28, 2017 19:06:29 Dmitry Olshansky via Digitalmars-d 
wrote:
 On Saturday, 28 October 2017 at 18:58:50 UTC, Andrei Alexandrescu

 wrote:
 I am using wine to build our Windows toolchain on Linux per
 https://wiki.dlang.org/Building_under_Posix. After building
 dmd, I tried to unittest druntime:

 wine make -f win32.mak

 and got this:

 core.exception.AssertError src\core\sync\mutex.d(380): unittest
 failure

 Is this reproducible? Does anyone have an attack on this?

 Wine is not particularly stable emulation software when it comes
 to testing Windows.

 I’d recommend using Windows evaluation for server in a virtual
 machine. 180 days for free + prolongation.

Depending on what you're doing, wine can work, but it's not trustworthy at
all. I originally developed std.datetime's Windows implementation in wine
and had to fix stuff later as a result, because wine didn't act the same
way, and I'm fairly certain that the std.datetime unit tests will fail in
wine right now because of some places where it doesn't match Windows.

I definitely run some stuff using wine, but at this point, I'd never develop
anything using wine. It's far too risky. IMHO, at best, it might make sense
to develop something initially in wine and then go fix it up in Windows
later, but if you accidentally depend on some buggy behavior in wine, you
could end up wasting a lot of time trying to fix it in Windows. And assuming
that something developed using wine will work in Windows is just asking to
shoot yourself in the foot.

I'm all for fixing issues we find where something works in Windows but not
wine so long as the fix doesn't negatively affect running stuff in Windows,
but in general, if something doesn't work in wine that worked in Windows,
the wine guys have a bug.

Granted, the wine guys have a really nasty job to do to get everything
working, and they've arguably worked miracles to get where they are, but the
end result still has lots of problems. Some stuff works well, and other
stuff doesn't work at all - and most annoyingly, those two things could swap
between two releases of wine.

- Jonathan M Davis

Kagamin <spam here.lot> writes:

On Saturday, 28 October 2017 at 18:58:50 UTC, Andrei Alexandrescu 
wrote:
 core.exception.AssertError src\core\sync\mutex.d(380): unittest 
 failure

That test is incorrect, see: 
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682552%28v=vs.85%29.aspx
 After a critical section object has been deleted, do not 
 reference the object in any function that operates on critical 
 sections (such as EnterCriticalSection, 
 TryEnterCriticalSection, and LeaveCriticalSection) other than 
 InitializeCriticalSection and 
 InitializeCriticalSectionAndSpinCount. If you attempt to do so, 
 memory corruption and other unexpected errors can occur.