We've just uploaded new binary releases to http://gdcproject.org/downloads/

## GDC changes ##

As we merged the first parts of Daniel Greens MinGW changes
back into GDC we now also provide initial (automated) MinGW builds.
These builds are mostly unsupported and will likely have many more bugs
than the older releases posted by Daniel so don't expect too much.

Other changes:
* Fixed gcc.attribute
* Added support for target attributes (import gcc.attribute;
  @attribute("naked"))  http://wiki.dlang.org/GDC/Using_GDC#Attributes

See https://github.com/D-Programming-GDC/GDC/commits/master for more details

## Toolchain changes ##
* Changed file permissions of toolchains to read/write
* Added READMEs to all toolchains
* Toolchain binaries ($TARGET-gdc) now show the build date,
  DMDFE version, and gdc git revision in --version output

## ARM changes ##
The arm native compilers should now run on older ARMv5 processors as
well. (Generated D code already worked on these processors, but the gdc
compiler did not run correctly on these systems)



There's also a new guide on the wiki showing how the filesystem of a
real machine can be used by cross-compilers. This way the
cross-compilers have access to all libraries installed on the machine.
http://wiki.dlang.org/GDC/Cross_Compiler/Existing_Sysroot#Sysroot_over_SSH

On 4 May 2014 10:38, Johannes Pfau via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
> We've just uploaded new binary releases to http://gdcproject.org/downloads/
>
> ## GDC changes ##
>
> As we merged the first parts of Daniel Greens MinGW changes
> back into GDC we now also provide initial (automated) MinGW builds.
> These builds are mostly unsupported and will likely have many more bugs
> than the older releases posted by Daniel so don't expect too much.
>
> Other changes:
> * Fixed gcc.attribute
> * Added support for target attributes (import gcc.attribute;
>   @attribute("naked"))  http://wiki.dlang.org/GDC/Using_GDC#Attributes
>
> See https://github.com/D-Programming-GDC/GDC/commits/master for more details
>
> ## Toolchain changes ##
> * Changed file permissions of toolchains to read/write
> * Added READMEs to all toolchains
> * Toolchain binaries ($TARGET-gdc) now show the build date,
>   DMDFE version, and gdc git revision in --version output
>
> ## ARM changes ##
> The arm native compilers should now run on older ARMv5 processors as
> well. (Generated D code already worked on these processors, but the gdc
> compiler did not run correctly on these systems)
>
>

## Backend changes ##

Debug generation changes are now stable.
Notable improvements:
- Debug generation of module / import statements are complete.  Only
missing GDB changes to effectively use them.
- Methods can now be seen as part of a class/struct
- Inheritance of class members and base objects are now correctly constructed.
- Manifest constants (limited to scalars only) are now visible in debug.

Also improved use of GDC with DUB, various fixes with all-at-once compilation and our warning/error/deprecation diagnostic model.

Regards
Iain.

On 04/05/2014 10:38, Johannes Pfau wrote:
> We've just uploaded new binary releases to
> http://gdcproject.org/downloads/
>
> ## GDC changes ##
>
> As we merged the first parts of Daniel Greens MinGW changes
> back into GDC we now also provide initial (automated) MinGW builds.
> These builds are mostly unsupported and will likely have many more bugs
> than the older releases posted by Daniel so don't expect too much.
>

Glad to hear there is some progress here, but are there plans to make this supported in the future?

Also, what is the difference between Daniel Green's build, and the native Standard Builds?


-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros

Am Wed, 07 May 2014 14:38:32 +0100
schrieb Bruno Medeiros <bruno.do.medeiros+dng@gmail.com>:

> On 04/05/2014 10:38, Johannes Pfau wrote:
> > We've just uploaded new binary releases to http://gdcproject.org/downloads/
> >
> > ## GDC changes ##
> >
> > As we merged the first parts of Daniel Greens MinGW changes
> > back into GDC we now also provide initial (automated) MinGW builds.
> > These builds are mostly unsupported and will likely have many more
> > bugs than the older releases posted by Daniel so don't expect too
> > much.
> >
> 
> Glad to hear there is some progress here, but are there plans to make this supported in the future?
> 
> Also, what is the difference between Daniel Green's build, and the native Standard Builds?
> 
> 

Daniels builds apply some more patches, see
https://github.com/venix1/MinGW-GDC for details.
The builds on gdcproject.org use the standard git sources of gdc which
only include the subset of these patches that's necessary to compile &
run a hello world program.

On 07/05/2014 17:42, Johannes Pfau wrote:
> Am Wed, 07 May 2014 14:38:32 +0100
> schrieb Bruno Medeiros <bruno.do.medeiros+dng@gmail.com>:
>
>> On 04/05/2014 10:38, Johannes Pfau wrote:
>>> We've just uploaded new binary releases to
>>> http://gdcproject.org/downloads/
>>>
>>> ## GDC changes ##
>>>
>>> As we merged the first parts of Daniel Greens MinGW changes
>>> back into GDC we now also provide initial (automated) MinGW builds.
>>> These builds are mostly unsupported and will likely have many more
>>> bugs than the older releases posted by Daniel so don't expect too
>>> much.
>>>
>>
>> Glad to hear there is some progress here, but are there plans to make
>> this supported in the future?
>>
>> Also, what is the difference between Daniel Green's build, and the
>> native Standard Builds?
>>
>>
>
> Daniels builds apply some more patches, see
> https://github.com/venix1/MinGW-GDC for details.
> The builds on gdcproject.org use the standard git sources of gdc which
> only include the subset of these patches that's necessary to compile &
> run a hello world program.
>

I'm not familiar with the internals of compiler and runtime architecture, but I'm curious, why is is that so many complicated patches are necessary?
I understand the D runtime has to access Windows API, correct? But that should all be available in the MinGW target as well, no? Otherwise, what is the difference here when DMD for Windows is compiled, vs when GDC is compiled?


-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros

On 9 May 2014 12:20, Bruno Medeiros via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
> On 07/05/2014 17:42, Johannes Pfau wrote:
>>
>> Am Wed, 07 May 2014 14:38:32 +0100
>> schrieb Bruno Medeiros <bruno.do.medeiros+dng@gmail.com>:
>>
>>> On 04/05/2014 10:38, Johannes Pfau wrote:
>>>>
>>>> We've just uploaded new binary releases to http://gdcproject.org/downloads/
>>>>
>>>> ## GDC changes ##
>>>>
>>>> As we merged the first parts of Daniel Greens MinGW changes
>>>> back into GDC we now also provide initial (automated) MinGW builds.
>>>> These builds are mostly unsupported and will likely have many more
>>>> bugs than the older releases posted by Daniel so don't expect too
>>>> much.
>>>>
>>>
>>> Glad to hear there is some progress here, but are there plans to make this supported in the future?
>>>
>>> Also, what is the difference between Daniel Green's build, and the native Standard Builds?
>>>
>>>
>>
>> Daniels builds apply some more patches, see
>> https://github.com/venix1/MinGW-GDC for details.
>> The builds on gdcproject.org use the standard git sources of gdc which
>> only include the subset of these patches that's necessary to compile &
>> run a hello world program.
>>
>
> I'm not familiar with the internals of compiler and runtime architecture, but I'm curious, why is is that so many complicated patches are necessary? I understand the D runtime has to access Windows API, correct? But that should all be available in the MinGW target as well, no? Otherwise, what is the difference here when DMD for Windows is compiled, vs when GDC is compiled?
>

DMD x86 on Windows uses the Digital Mars toolchain for linking, etc.
DMD x86_64 on Windows uses the MSVC toolchain for linking, etc.
GDC on Windows uses the GNU toolchain for linking, etc.

Another potentially crucial difference is that DMD compiles directly to object file.  GCC requires an assembler installed.  This probably does make it easier for DMD to invented custom sections for its own abuse.

On 09/05/2014 15:34, Iain Buclaw via Digitalmars-d-announce wrote:
> On 9 May 2014 12:20, Bruno Medeiros via Digitalmars-d-announce
> <digitalmars-d-announce@puremagic.com> wrote:
>> On 07/05/2014 17:42, Johannes Pfau wrote:
>>>
>>> Am Wed, 07 May 2014 14:38:32 +0100
>>> schrieb Bruno Medeiros <bruno.do.medeiros+dng@gmail.com>:
>>>
>>>> On 04/05/2014 10:38, Johannes Pfau wrote:
>>>>>
>>>>> We've just uploaded new binary releases to
>>>>> http://gdcproject.org/downloads/
>>>>>
>>>>> ## GDC changes ##
>>>>>
>>>>> As we merged the first parts of Daniel Greens MinGW changes
>>>>> back into GDC we now also provide initial (automated) MinGW builds.
>>>>> These builds are mostly unsupported and will likely have many more
>>>>> bugs than the older releases posted by Daniel so don't expect too
>>>>> much.
>>>>>
>>>>
>>>> Glad to hear there is some progress here, but are there plans to make
>>>> this supported in the future?
>>>>
>>>> Also, what is the difference between Daniel Green's build, and the
>>>> native Standard Builds?
>>>>
>>>>
>>>
>>> Daniels builds apply some more patches, see
>>> https://github.com/venix1/MinGW-GDC for details.
>>> The builds on gdcproject.org use the standard git sources of gdc which
>>> only include the subset of these patches that's necessary to compile &
>>> run a hello world program.
>>>
>>
>> I'm not familiar with the internals of compiler and runtime architecture,
>> but I'm curious, why is is that so many complicated patches are necessary?
>> I understand the D runtime has to access Windows API, correct? But that
>> should all be available in the MinGW target as well, no? Otherwise, what is
>> the difference here when DMD for Windows is compiled, vs when GDC is
>> compiled?
>>
>
> DMD x86 on Windows uses the Digital Mars toolchain for linking, etc.
> DMD x86_64 on Windows uses the MSVC toolchain for linking, etc.
> GDC on Windows uses the GNU toolchain for linking, etc.
>

Yeah, this much I knew already.

> Another potentially crucial difference is that DMD compiles directly
> to object file.  GCC requires an assembler installed.  This probably
> does make it easier for DMD to invented custom sections for its own
> abuse.
>

So it's not so much the D runtime (the 'core', 'rt', 'gc', etc, modules of the D standard library) that is lacking and in need of patches/changes, but rather the DMD frontend and code generator, right?
If so, I think I understand.

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros