www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Building phobos with wine fails

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
I've followed the instructions at 
https://wiki.dlang.org/Building_under_Posix to build posix on Win32 
using wine (awesome possum!). It works great for building dmd and then 
druntime. However when I try to build phobos I get the odd errors pasted 
below. Any ideas on why that is happening? Thanks! -- Andrei

std\xml.d(1650): Error: function std.xml.Item.opEquals does not override 
any function, did you mean to override 'object.Object.opEquals'?
std\xml.d(1653): Error: function std.xml.Item.opCmp does not override 
any function, did you mean to override 'object.Object.opCmp'?
std\xml.d(1273): Error: function std.xml.Comment.opEquals does not 
override any function, did you mean to override 'object.Object.opEquals'?
std\xml.d(1292): Error: function std.xml.Comment.opCmp does not override 
any function, did you mean to override 'object.Object.opCmp'?
std\xml.d(1313): Error: function std.xml.Comment.isEmptyXML does not 
override any function
std\xml.d(1361): Error: function std.xml.CData.opEquals does not 
override any function, did you mean to override 'object.Object.opEquals'?
std\xml.d(1380): Error: function std.xml.CData.opCmp does not override 
any function, did you mean to override 'object.Object.opCmp'?
std\xml.d(1401): Error: function std.xml.CData.isEmptyXML does not 
override any function
std\xml.d(1438): Error: function std.xml.Text.opEquals does not override 
any function, did you mean to override 'object.Object.opEquals'?
std\xml.d(1457): Error: function std.xml.Text.opCmp does not override 
any function, did you mean to override 'object.Object.opCmp'?
std\xml.d(1481): Error: function std.xml.Text.isEmptyXML does not 
override any function
std\xml.d(1521): Error: function std.xml.XMLInstruction.opEquals does 
not override any function, did you mean to override 
'object.Object.opEquals'?
std\xml.d(1540): Error: function std.xml.XMLInstruction.opCmp does not 
override any function, did you mean to override 'object.Object.opCmp'?
std\xml.d(1561): Error: function std.xml.XMLInstruction.isEmptyXML does 
not override any function
std\xml.d(1601): Error: function std.xml.ProcessingInstruction.opEquals 
does not override any function, did you mean to override 
'object.Object.opEquals'?
std\xml.d(1620): Error: function std.xml.ProcessingInstruction.opCmp 
does not override any function, did you mean to override 
'object.Object.opCmp'?
std\xml.d(1641): Error: function 
std.xml.ProcessingInstruction.isEmptyXML does not override any function
Jul 01 2017
next sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Saturday, 1 July 2017 at 21:09:47 UTC, Andrei Alexandrescu 
wrote:

 I've followed the instructions at 
 https://wiki.dlang.org/Building_under_Posix to build posix on 
 Win32 using wine (awesome possum!). It works great for building 
 dmd and then druntime. However when I try to build phobos I get 
 the odd errors pasted below. Any ideas on why that is 
 happening? Thanks! -- Andrei

 [...]


It is unclear what you're trying to do, why would you build the 
Posix versions of D under Wine?  I ran the Windows version of D 
under Wine around 7 years ago and didn't have a problem, though I 
don't think I ran the tests.
Jul 01 2017
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 07/01/2017 05:37 PM, Joakim wrote:

 On Saturday, 1 July 2017 at 21:09:47 UTC, Andrei Alexandrescu wrote:

 I've followed the instructions at 
 https://wiki.dlang.org/Building_under_Posix to build posix on Win32 
 using wine (awesome possum!). It works great for building dmd and then 
 druntime. However when I try to build phobos I get the odd errors 
 pasted below. Any ideas on why that is happening? Thanks! -- Andrei

 [...]


 
 It is unclear what you're trying to do, why would you build the Posix 
 versions of D under Wine?  I ran the Windows version of D under Wine 
 around 7 years ago and didn't have a problem, though I don't think I ran 
 the tests.


Was trying to repro the win32 errors in 
https://github.com/dlang/phobos/pull/5472 without installing windows. I 
was building the win32, not the posix binaries. -- Andrei
Jul 01 2017
prev sibling next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
Andrei Alexandrescu wrote:


 I've followed the instructions at 
 https://wiki.dlang.org/Building_under_Posix to build posix on Win32 using 
 wine (awesome possum!). It works great for building dmd and then 
 druntime. However when I try to build phobos I get the odd errors pasted 
 below. Any ideas on why that is happening? Thanks! -- Andrei


i bet you forgot to pass DMD to make. both druntime and phobos should be 
built with:

	wine make DMD=../dmd/src/dmd.exe -fwin32.mak

where DMD=... is the path to dmd.exe you just built at the first step.

wiki is severely incomplete and outdated.
Jul 01 2017
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
On 7/1/17 6:06 PM, ketmar wrote:

 Andrei Alexandrescu wrote:
 

 I've followed the instructions at 
 https://wiki.dlang.org/Building_under_Posix to build posix on Win32 
 using wine (awesome possum!). It works great for building dmd and then 
 druntime. However when I try to build phobos I get the odd errors 
 pasted below. Any ideas on why that is happening? Thanks! -- Andrei


 
 i bet you forgot to pass DMD to make. both druntime and phobos should be 
 built with:
 
      wine make DMD=../dmd/src/dmd.exe -fwin32.mak
 
 where DMD=... is the path to dmd.exe you just built at the first step.


Probably not the problem. I've added the path to Path in the registry 
and dmd is found fine - it does compile certain files.


 wiki is severely incomplete and outdated.


The wine guide has been created by Razvan Nitu, my student, two weeks ago.


Thanks,

Andrei
Jul 01 2017
next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
..so be it. if you said that it is not a problem, than it is not a 
problem. sorry for helping.
Jul 01 2017
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Sunday, 2 July 2017 at 01:46:14 UTC, Andrei Alexandrescu wrote:

 Probably not the problem.


Did you actually try it? Might as well rule it out.

I find building on Windows (including with wine) is an absolute 
mess. Have to edit the makefile and it git clones something into 
../..???? WTF.
Jul 01 2017
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 07/01/2017 11:31 PM, Adam D. Ruppe wrote:

 On Sunday, 2 July 2017 at 01:46:14 UTC, Andrei Alexandrescu wrote:

 Probably not the problem.


 
 Did you actually try it? Might as well rule it out.


I did, but had a typo. Yay, it worked. Thanks ketmar. I'll add the info 
to the wiki.


 I find building on Windows (including with wine) is an absolute mess. 
 Have to edit the makefile and it git clones something into ../..???? WTF.


Yah, I also found it odd that dmd's make tries to execute git (I don't 
have it installed for Windows). The build does succeed though.


Andrei
Jul 02 2017
prev sibling next sibling parent Stefan Koch <uplink.coder googlemail.com> writes:
On Saturday, 1 July 2017 at 21:09:47 UTC, Andrei Alexandrescu 
wrote:

 I've followed the instructions at 
 https://wiki.dlang.org/Building_under_Posix to build posix on 
 Win32 using wine (awesome possum!). It works great for building 
 dmd and then druntime. However when I try to build phobos I get 
 the odd errors pasted below. Any ideas on why that is 
 happening? Thanks! -- Andrei

 [...]


looks like a druntime/phobos mismatch.
Jul 01 2017
prev sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Saturday, July 01, 2017 17:09:47 Andrei Alexandrescu via Digitalmars-d 
wrote:

 I've followed the instructions at
 https://wiki.dlang.org/Building_under_Posix to build posix on Win32
 using wine (awesome possum!). It works great for building dmd and then
 druntime. However when I try to build phobos I get the odd errors pasted
 below. Any ideas on why that is happening? Thanks! -- Andrei

 std\xml.d(1650): Error: function std.xml.Item.opEquals does not override
 any function, did you mean to override 'object.Object.opEquals'?


[...]

Well, that looks bad, and it really should be working better than that, but
I would point out that (at least, the last time I checked), wine does not
behave correctly with regards to some of the date/time stuff, so some of the
std.datetime tests will fail with wine, and fixing that requires that wine
start behaving like Windows like it's supposed to. So, best case, at least
some Phobos tests will fail under wine, but it _should_ work to at least
build and use dmd and Phobos under wine. It just will have some of the
issues that you typically get running windows applications under wine. I
haven't done it in years though, so I have no idea how up-to-date those
instructions are.

- Jonathan M Davis
Jul 03 2017
parent reply Shachar Shemesh <shachar weka.io> writes:
On 03/07/17 15:35, Jonathan M Davis via Digitalmars-d wrote:

 Well, that looks bad, and it really should be working better than that, but
 I would point out that (at least, the last time I checked), wine does not
 behave correctly with regards to some of the date/time stuff, so some of the
 std.datetime tests will fail with wine, and fixing that requires that wine
 start behaving like Windows like it's supposed to.


Do you have specific examples? My Wine hacking days are long behind me, 
but I'm fairly sure such easy wins would be simple enough fix to get 
into Wine.

The Wine charter is to be "bug for bug compatible with Windows", so such 
changes should not have any trouble to make it in, assuming we can 
supply a test that proves that's the case.

Shachar
Jul 03 2017
parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Monday, July 03, 2017 15:43:57 Shachar Shemesh via Digitalmars-d wrote:

 On 03/07/17 15:35, Jonathan M Davis via Digitalmars-d wrote:

 Well, that looks bad, and it really should be working better than that,
 but I would point out that (at least, the last time I checked), wine
 does not behave correctly with regards to some of the date/time stuff,
 so some of the std.datetime tests will fail with wine, and fixing that
 requires that wine start behaving like Windows like it's supposed to.


 Do you have specific examples? My Wine hacking days are long behind me,
 but I'm fairly sure such easy wins would be simple enough fix to get
 into Wine.

 The Wine charter is to be "bug for bug compatible with Windows", so such
 changes should not have any trouble to make it in, assuming we can
 supply a test that proves that's the case.


Two come to mind:

1. The functions for converting to and from a timezone take a struct
containing information about what that timezone is - including the DST
switches. The way that MS did that orginally involved specifying something
like the nth instance of the xth day of the week in a particular month (e.g.
the first Sunday in April), and that was for all time, as if time zones
never changed when they have DST switches - which of course, doesn't work
well for many timezones (there's even a wikipedia article on how Windows
kept having the time wrong in Israel because of this). MS didn't bother to
fix this until the US and Canada changed when DST was going to be starting
in 2007.

To fix this for Vista, MS added a new version of these functions which
assume that the DST rules are good for a particular year (which still isn't
entirely correct but at least is _much_ closer), but they couldn't
retroactively add that to existing programs. Anything using the old
functions would still be broken. Their solution seems to have been to make
it so that the old versions of those functions look at the struct that
they're given, figure out which timezone they're for, and then ignore what's
in the struct and use whatever the rules are supposed to be for that
particular date. Without that change, you end up using the old DST rules,
and last time I checked, wine had not made that change. So, if you used the
old functions (which IIRC, std.datetime does, because at the time it was
written, we were trying to support Windows XP), and you use wine, then DST
will be wrong for some dates which would be correct on Windows. I had
actually originally developed std.datetime's Windows stuff using wine, so I
had buggy code because of this, which was caught as soon as someone (I
forget whether it was me or someone else) actually ran the tests on an
actual Windows box.

2. The time zone conversion stuff in Windows is unfortunately defined in the
registry, and AFAIK, the only way to look up an arbitrary time zone instead
of using local time or UTC is to read in the information from the registry
and fill in the aforementioned struct with time zone information with that
information. The time zones are listed in the registry based on the English
names that MS uses - e.g. "Pacific Standard Time" is what they use for the
Pacific time zone (though it has both the standard time and DST information
in there). Pretty much every other OS uses the time zone database for their
time zone information, and that uses major cities to distinguish time zones
(e.g. the Pacific time zone would be "America/Los_Angeles"), not something
like "Pacific Standard Time". wine chose to use the time zone database names
like "America/Los_Angeles" in their registry instead of the names that
Windows uses. So, any Windows program that tries to look up a time zone with
wine will fail, because wine is not using the names that Windows uses even
though they're supposedly mimicking the Windows registry. To work around
that, when I wrote std.datetime, I was actually looking at each time zone
registry entry to look at the name it had for standard time (since it was
the same name as the registry key on Windows), so it _was_ compatible with
wine. However, as it turns out, the values in the registry entry are
locale-dependent (unlike the registry key itself, which is always in
Engish). So, the tests failed on systems for folks outside the US (e.g.
Kenji, being in Japan, ran into the issue and was actually the one to fix it
so that std.datetime used the registry key rather than looking into the
entry for the time zone name).

I have not actually tested any of that with wine recently, so it's possible
that they've fixed one or both of those issues or that it's fixed if you
tell it that you're using a newer version of Windows, but the last time I
checked, both of those were still broken on wine. And I really should have
created issues in the wine bug tracker for them, but I've just never gotten
around to it.

But it's the sort of thing that you probably don't catch unless you're
dealign with specific time zone stuff in a way that most programs don't do.

- Jonathan M Davis
Jul 03 2017
parent reply Shachar Shemesh <shachar weka.io> writes:
On 03/07/17 16:59, Jonathan M Davis via Digitalmars-d wrote:


 1. The functions for converting to and from a timezone take a struct
 containing information about what that timezone is - including the DST
 switches. The way that MS did that orginally involved specifying something
 like the nth instance of the xth day of the week in a particular month (e.g.
 the first Sunday in April), and that was for all time, as if time zones
 never changed when they have DST switches - which of course, doesn't work
 well for many timezones (there's even a wikipedia article on how Windows
 kept having the time wrong in Israel because of this). MS didn't bother to
 fix this until the US and Canada changed when DST was going to be starting
 in 2007.


Considering that wikipedia article used to link to *my* site for how to 
fix this, I think I safely say "I know".

In fact, MS used to link to my site for a solution, which hilarious, 
because by "my site", I mean "my company", which was named "Lingnu Open 
Source Consulting Ltd.".


 Without that change, you end up using the old DST rules,
 and last time I checked, wine had not made that change. So, if you used the
 old functions (which IIRC, std.datetime does, because at the time it was
 written, we were trying to support Windows XP), and you use wine, then DST
 will be wrong for some dates which would be correct on Windows.


Sounds easy enough to both create a unit test and fix. Let's see if 
Alexandre will take my patches after so many years[1] :-).


 
 2. The time zone conversion stuff in Windows is unfortunately defined in the
 registry, and AFAIK, the only way to look up an arbitrary time zone instead
 of using local time or UTC is to read in the information from the registry
 and fill in the aforementioned struct with time zone information with that
 information. The time zones are listed in the registry based on the English
 names that MS uses - e.g. "Pacific Standard Time" is what they use for the
 Pacific time zone (though it has both the standard time and DST information
 in there). Pretty much every other OS uses the time zone database for their
 time zone information, and that uses major cities to distinguish time zones
 (e.g. the Pacific time zone would be "America/Los_Angeles"), not something
 like "Pacific Standard Time". wine chose to use the time zone database names
 like "America/Los_Angeles" in their registry instead of the names that
 Windows uses


That one sounds like potentially harder to fix. I'll ask on the wine 
lists and see if anything comes up.

Also, note that even if I submit patches, and they get merged, it's 
around a year until major distributions pick that up.

Still, better late than never.

Shachar

1 - By which I mean that maybe, after so many years, he now will.
Jul 03 2017
parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Monday, July 03, 2017 19:57:35 Shachar Shemesh via Digitalmars-d wrote:

 On 03/07/17 16:59, Jonathan M Davis via Digitalmars-d wrote:

 1. The functions for converting to and from a timezone take a struct
 containing information about what that timezone is - including the DST
 switches. The way that MS did that orginally involved specifying
 something like the nth instance of the xth day of the week in a
 particular month (e.g. the first Sunday in April), and that was for all
 time, as if time zones never changed when they have DST switches -
 which of course, doesn't work well for many timezones (there's even a
 wikipedia article on how Windows kept having the time wrong in Israel
 because of this). MS didn't bother to fix this until the US and Canada
 changed when DST was going to be starting in 2007.


 Considering that wikipedia article used to link to *my* site for how to
 fix this, I think I safely say "I know".

 In fact, MS used to link to my site for a solution, which hilarious,
 because by "my site", I mean "my company", which was named "Lingnu Open
 Source Consulting Ltd.".


LOL. I did not know that, though since IIRC, you're one of the guys who
works at Weka, it does not surprise me that you'd be aware of how badly MS
has dealt with Israel and time zones.


 Without that change, you end up using the old DST rules,
 and last time I checked, wine had not made that change. So, if you used
 the old functions (which IIRC, std.datetime does, because at the time
 it was written, we were trying to support Windows XP), and you use
 wine, then DST will be wrong for some dates which would be correct on
 Windows.


 Sounds easy enough to both create a unit test and fix. Let's see if
 Alexandre will take my patches after so many years[1] :-).


It probably isn't terribly hard. I've just never gotten around to dealing
with it.


 2. The time zone conversion stuff in Windows is unfortunately defined in
 the registry, and AFAIK, the only way to look up an arbitrary time zone
 instead of using local time or UTC is to read in the information from
 the registry and fill in the aforementioned struct with time zone
 information with that information. The time zones are listed in the
 registry based on the English names that MS uses - e.g. "Pacific
 Standard Time" is what they use for the Pacific time zone (though it
 has both the standard time and DST information in there). Pretty much
 every other OS uses the time zone database for their time zone
 information, and that uses major cities to distinguish time zones (e.g.
 the Pacific time zone would be "America/Los_Angeles"), not something
 like "Pacific Standard Time". wine chose to use the time zone database
 names like "America/Los_Angeles" in their registry instead of the names
 that Windows uses


 That one sounds like potentially harder to fix. I'll ask on the wine
 lists and see if anything comes up.


Yeah, it wouldn't surprise me if wine were doing something where it expected
to be able to link the registry keys to the time zone files on disk (I don't
know why else they would have done it that way). And as such, it's probably
not exactly a quick and easy fix. All of that is probably at least somewhat
buggy though given the discrepancies between the time zones that *nix uses
and the ones that Windows uses. Fortunately, few programs are going to care
about the exact conversions at any specific point in time so long as it's
close. But regardless, what they've done with the registry keys makes it
impossible to look up a specific time zone without realizing that you're
running in wine and doing something differently for wine (which goes against
the whole bug-for-bug compatibility thing).


 Also, note that even if I submit patches, and they get merged, it's
 around a year until major distributions pick that up.

 Still, better late than never.


Indeed.

- Jonathan M Davis
Jul 03 2017