www.digitalmars.com         C & C++   DMDScript  

D.gnu - MinGW64 Build Instructions

reply Daniel Green <venix1 gmail.com> writes:
https://bitbucket.org/goshawk/gdc/wiki/MinGW64

The above link details the process of building GDC with TDM64.  The 
instructions are not great at the moment.  It's getting late and I 
rushed them.  I'll get the patches posted sometime tomorrow.

Post any questions or comments in this newsgroup and I'll do my best to 
answer them.
Apr 29 2011
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
On 4/30/2011 1:42 AM, Daniel Green wrote:

 https://bitbucket.org/goshawk/gdc/wiki/MinGW64

 The above link details the process of building GDC with TDM64. The
 instructions are not great at the moment. It's getting late and I rushed
 them. I'll get the patches posted sometime tomorrow.

 Post any questions or comments in this newsgroup and I'll do my best to
 answer them.


Nice!  Based on your other post, I'm a little confused.  Is this a 
barebones 64-bit compiler, or is it at least an attempt to patch Phobos 
and druntime to work on Win64?  Right now pretty much all time/energy I 
have for D work is being devoted to tracking down the Heisenbug from 
Hell in std.parallelism (which I think might actually be a codegen bug 
that's messing with the low order bits of pointers), so I won't have 
time to look at this in much detail until that gets fixed, but after 
that I'll be willing to put it through some serious testing.
Apr 30 2011
parent Daniel Green <venix1 gmail.com> writes:
On 4/30/2011 3:20 PM, dsimcha wrote:

 Nice! Based on your other post, I'm a little confused. Is this a
 barebones 64-bit compiler, or is it at least an attempt to patch Phobos
 and druntime to work on Win64?


I've attempted to patch Phobos and got it to compile.  I think there are 
issues resulting from Win64 calling conventions not prefixing '_' to 
symbols.  Most of the changes are uint/ulong casts.  So it was 
surprisingly easier than I had imagined.
Apr 30 2011
prev sibling next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
On 4/30/2011 1:42 AM, Daniel Green wrote:

 https://bitbucket.org/goshawk/gdc/wiki/MinGW64

 The above link details the process of building GDC with TDM64. The
 instructions are not great at the moment. It's getting late and I rushed
 them. I'll get the patches posted sometime tomorrow.

 Post any questions or comments in this newsgroup and I'll do my best to
 answer them.


Now that you have the patches "officially" submitted, are you going to 
post binaries?
May 14 2011
parent Daniel Green <venix1 gmail.com> writes:
On 5/14/2011 11:02 PM, dsimcha wrote:

 Now that you have the patches "officially" submitted, are you going to
 post binaries?


I'll get binaries posted when I have a build script that can go from 
start to finish without human intervention.
May 17 2011
prev sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Sat, 30 Apr 2011 08:42:57 +0300, Daniel Green <venix1 gmail.com> wrote:


 https://bitbucket.org/goshawk/gdc/wiki/MinGW64

 The above link details the process of building GDC with TDM64.  The  
 instructions are not great at the moment.  It's getting late and I  
 rushed them.  I'll get the patches posted sometime tomorrow.

 Post any questions or comments in this newsgroup and I'll do my best to  
 answer them.


I took the liberty of cleaning up the instructions a bit.

However, it doesn't look like the Phobos in HG tip is ready for 64-bit.  
There were some trivial problems in std.stream, but lots of  
warnings/errors in the GC.

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net
May 25 2011
parent reply Daniel Green <venix1 gmail.com> writes:
On 5/25/2011 6:59 PM, Vladimir Panteleev wrote:

 However, it doesn't look like the Phobos in HG tip is ready for 64-bit.
 There were some trivial problems in std.stream, but lots of
 warnings/errors in the GC.


Is that with the patch?  The errors should be uint to size_t 
conversions.  However, I ran across linker issues becuase of calling 
conventions. Symbols used by the GC, __data_start__ are still exported, 
by the linker scripts, with Win32 calling conventions causing unresolved 
symbol errors when searching for the Win64 version.

Also, is that D1?  I don't recall D2 spitting out as many GC warnings 
but instead had a lot of Windows specific errors.
May 27 2011
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Fri, 27 May 2011 23:52:33 +0300, Daniel Green <venix1 gmail.com> wrote:


 On 5/25/2011 6:59 PM, Vladimir Panteleev wrote:

 However, it doesn't look like the Phobos in HG tip is ready for 64-bit.
 There were some trivial problems in std.stream, but lots of
 warnings/errors in the GC.


 Is that with the patch?


Where is the patch? In the original post you said you'd post the patches  
"tomorrow", but I haven't seen them here or linked from the building  
instructions.


 The errors should be uint to size_t conversions.  However, I ran across  
 linker issues becuase of calling conventions. Symbols used by the GC,  
 __data_start__ are still exported, by the linker scripts, with Win32  
 calling conventions causing unresolved symbol errors when searching for  
 the Win64 version.


Here's what I'm getting:

../../../libphobos/internal/gc/gcx.d:900: Error: function  
win32.os_query_staticdataseg (void**,uint*) does not match parameter types  
(void**,ulong*)
../../../libphobos/internal/gc/gcx.d:900: Error: cannot implicitly convert  
expression (& nbytes) of type ulong* to uint*
../../../libphobos/internal/gc/gcx.d:917: Error: function  
win32.os_query_staticdataseg (void**,uint*) does not match parameter types  
(void**,ulong*)
../../../libphobos/internal/gc/gcx.d:917: Error: cannot implicitly convert  
expression (& nbytes) of type ulong* to uint*


 Also, is that D1?  I don't recall D2 spitting out as many GC warnings  
 but instead had a lot of Windows specific errors.


Yep, this is D1.

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net
May 27 2011
parent reply Daniel Green <venix1 gmail.com> writes:
On 5/27/2011 4:55 PM, Vladimir Panteleev wrote:

 Where is the patch? In the original post you said you'd post the patches
 "tomorrow", but I haven't seen them here or linked from the building
 instructions.


Forgot to mention it but all patches relating to Win64 support can be 
found here.

https://bitbucket.org/goshawk/gdc/issue/206/win64-support


 Here's what I'm getting:

 ../../../libphobos/internal/gc/gcx.d:900: Error: function
 win32.os_query_staticdataseg (void**,uint*) does not match parameter
 types (void**,ulong*)
 ../../../libphobos/internal/gc/gcx.d:900: Error: cannot implicitly
 convert expression (& nbytes) of type ulong* to uint*
 ../../../libphobos/internal/gc/gcx.d:917: Error: function
 win32.os_query_staticdataseg (void**,uint*) does not match parameter
 types (void**,ulong*)
 ../../../libphobos/internal/gc/gcx.d:917: Error: cannot implicitly
 convert expression (& nbytes) of type ulong* to uint*


You have to change os_query_staticdataseg in win32.d it's done in the 
patch.
May 27 2011
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Sat, 28 May 2011 06:32:02 +0300, Daniel Green <venix1 gmail.com> wrote:


 You have to change os_query_staticdataseg in win32.d it's done in the  
 patch.


Thanks, didn't expect that part to be that simple.

The next obstacle seems to be _aApplycdzd/_aApplywdzd linking errors. I  
have no idea where gdc is getting that function name from. It seems to  
want _aApplycd1 and _aApplywd1 from internal/aApply.d, but I've no idea  
where the "zd" is coming from.

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net
May 27 2011
parent reply Daniel Green <venix1 gmail.com> writes:
On 5/28/2011 1:53 AM, Vladimir Panteleev wrote:

 On Sat, 28 May 2011 06:32:02 +0300, Daniel Green <venix1 gmail.com> wrote:


 You have to change os_query_staticdataseg in win32.d it's done in the
 patch.


 Thanks, didn't expect that part to be that simple.

 The next obstacle seems to be _aApplycdzd/_aApplywdzd linking errors. I
 have no idea where gdc is getting that function name from. It seems to
 want _aApplycd1 and _aApplywd1 from internal/aApply.d, but I've no idea
 where the "zd" is coming from.


I think the problem is likely to be the Win64 calling convention.  Win64 
no longer uses _ prefix for symbol names.  Can dump the symbols for the 
object file and see if "aApplycdzd" exists?
May 28 2011
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Sat, 28 May 2011 22:46:17 +0300, Daniel Green <venix1 gmail.com> wrote:


 On 5/28/2011 1:53 AM, Vladimir Panteleev wrote:

 On Sat, 28 May 2011 06:32:02 +0300, Daniel Green <venix1 gmail.com>  
 wrote:


 You have to change os_query_staticdataseg in win32.d it's done in the
 patch.


 Thanks, didn't expect that part to be that simple.

 The next obstacle seems to be _aApplycdzd/_aApplywdzd linking errors. I
 have no idea where gdc is getting that function name from. It seems to
 want _aApplycd1 and _aApplywd1 from internal/aApply.d, but I've no idea
 where the "zd" is coming from.


 I think the problem is likely to be the Win64 calling convention.  Win64  
 no longer uses _ prefix for symbol names.  Can dump the symbols for the  
 object file and see if "aApplycdzd" exists?


Pretty sure it's not the calling convention. aApplycdzd exists only in the  
object files for modules which use foreach (dchar c; someString).

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net
May 29 2011
parent Daniel Green <venix1 gmail.com> writes:
On 5/29/2011 4:20 AM, Vladimir Panteleev wrote:

 Pretty sure it's not the calling convention. aApplycdzd exists only in
 the object files for modules which use foreach (dchar c; someString).


I looked into the issue and the problem lines with the use of sprintf in 
the compiler source.  Line 1833 of statement.c.

---
int j = sprintf(fdname, "_aApply%s%.*s%zd", r, 2, fntab[flag], dim);
---

%zd is not supported by MSVCRT sprintf causing _aApplycdzd.  What I'm 
curious about is why this issue only surfaced with 64-bit support.

I've included a patch that solves the issue by enabling MinGW's ANSI 
printf replacements.  I'll apply it to the the repository later.
Jun 01 2011