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

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

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

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.