www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - GDC binaries updated

reply Johannes Pfau <nospam example.com> writes:
We've just uploaded new binary releases to
http://gdcproject.org/downloads/



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


* 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


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
May 04 2014
next sibling parent Iain Buclaw via Digitalmars-d-announce writes:
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/



 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


 * 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


 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)




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.
May 04 2014
prev sibling parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 04/05/2014 10:38, Johannes Pfau wrote:

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



 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
May 07 2014
parent reply Johannes Pfau <nospam example.com> writes:
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/



 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.
May 07 2014
parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
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/



 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
May 09 2014
parent reply Iain Buclaw via Digitalmars-d-announce writes:
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/



 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.
May 09 2014
parent Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
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/



 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
May 13 2014