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 next 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 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 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 Daniel Green <venix1 gmail.com> writes:
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling parent "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