www.digitalmars.com         C & C++   DMDScript  

D.gnu - MinGW Release. D2.058 x86-64 20120428

reply Daniel Green <venix1 gmail.com> writes:
** Fixes, previous unresolved _Dmodule_ref **

Please post all issues in D.gnu or on GDC's site 
https://bitbucket.org/goshawk/gdc

Due to the use of a newer runtime than TDM64-GCC it is **recommended** 
to install a copy specifically for GDC.

Features
  **ALPHA** As in, D2.058 support is still new.
  * D2.058
  * Debug information available using gnu-debuglink.
  * Removed D1(Did anyone use this featuer?).
    * Due to current system breaking with repository changes and D1
      being discontinued at the end of the year.
  * binutils with TLS patches
  * mingw-w64-runtime with TLS and stdio fixes.
  * GCC 4.6.1 with TLS patches

Installation instructions:

1. Download and install TDM MinGW64
2. Extract the downloaded archive into the base of the newly installed 
TDM install.

If you've done this before, you can just do step 2.

MinGW64 installer
http://tdm-gcc.tdragon.net/

GDC binary
https://bitbucket.org/goshawk/gdc/downloads/gcc-4.6.1-tdm64-1-gdc-7e1a98da2769-20120428-D2.058.7z

Known issues:
  * May break TDM64 C++.
  * Field-less structs will throw a null this exception.  When formatted 
by std.format.  runnable/test23.d
Apr 28 2012
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 28.04.2012 21:08, Daniel Green wrote:

 ** Fixes, previous unresolved _Dmodule_ref **


Nice, it works so far :)

And where as previous version promptly segfaulted on my regex benchmark 
this one goes through. And the compiled binary performance is not bad 
either:

Small test - searching for all \S+ \S+ (rough "email") in 40Mb of 
man-like text.

dmd: 5.48sec
gdc: 3.30sec

Cool, surely gone use it side by side with dmd.

P.S. Command line options:
dmd -O -release -noboundscheck
gdc -Ofast -frelease

-- 
Dmitry Olshansky
Apr 28 2012
parent reply Manu <turkeyman gmail.com> writes:
I guess the etc.c... libs didn't make the cut :(

On 28 April 2012 22:35, Dmitry Olshansky <dmitry.olsh gmail.com> wrote:


 On 28.04.2012 21:08, Daniel Green wrote:


 ** Fixes, previous unresolved _Dmodule_ref **


 Nice, it works so far :)

 And where as previous version promptly segfaulted on my regex benchmark
 this one goes through. And the compiled binary performance is not bad
 either:

 Small test - searching for all \S+ \S+ (rough "email") in 40Mb of
 man-like text.

 dmd: 5.48sec
 gdc: 3.30sec

 Cool, surely gone use it side by side with dmd.

 P.S. Command line options:
 dmd -O -release -noboundscheck
 gdc -Ofast -frelease

 --
 Dmitry Olshansky
Apr 30 2012
parent reply Daniel Green <venix1 gmail.com> writes:
On 4/30/2012 6:18 AM, Manu wrote:

 I guess the etc.c... libs didn't make the cut :(


It was sort of an intermittent release, to get it out and tested.

To update the lib status, zlib is already part of libgphobos2.a.  If you 
inspect the library you'll see it's object files.  If you're having 
specific zlib errors, you should share them.

sqlite.o is easy enough to build and can be put into libgphobos.a. 
Being public domain helps, I'll add it to the build process.

Curl is the only tricky one.  It actually has configuration options and 
probably dependencies.  Is there a list of what features D requires curl 
to support?
Apr 30 2012
next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 30 April 2012 16:33, Daniel Green <venix1 gmail.com> wrote:

 On 4/30/2012 6:18 AM, Manu wrote:

 I guess the etc.c... libs didn't make the cut :(



 It was sort of an intermittent release, to get it out and tested.

 To update the lib status, zlib is already part of libgphobos2.a. =A0If yo=


u

 inspect the library you'll see it's object files. =A0If you're having spe=


cific

 zlib errors, you should share them.

 sqlite.o is easy enough to build and can be put into libgphobos.a. Being
 public domain helps, I'll add it to the build process.

 Curl is the only tricky one. =A0It actually has configuration options and
 probably dependencies. =A0Is there a list of what features D requires cur=


l to

 support?


SQLite comes as a single source file if I recall correctly, and could
be added to the libphobos build folder under libphobos/sqlite.

In future when (or if) shared libraries are supported, can remove the
source file and have these as dependencies for building libphobos,
which are linked in during compilation of libgphobos.so

--=20
Iain Buclaw

*(p < e ? p++ : p) =3D (c & 0x0f) + '0';
Apr 30 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
On 30 April 2012 18:40, Iain Buclaw <ibuclaw ubuntu.com> wrote:


 On 30 April 2012 16:33, Daniel Green <venix1 gmail.com> wrote:

 On 4/30/2012 6:18 AM, Manu wrote:

 I guess the etc.c... libs didn't make the cut :(



 It was sort of an intermittent release, to get it out and tested.

 To update the lib status, zlib is already part of libgphobos2.a.  If you
 inspect the library you'll see it's object files.  If you're having


 specific

 zlib errors, you should share them.

 sqlite.o is easy enough to build and can be put into libgphobos.a. Being
 public domain helps, I'll add it to the build process.

 Curl is the only tricky one.  It actually has configuration options and
 probably dependencies.  Is there a list of what features D requires curl


 to

 support?


 SQLite comes as a single source file if I recall correctly, and could
 be added to the libphobos build folder under libphobos/sqlite.

 In future when (or if) shared libraries are supported, can remove the
 source file and have these as dependencies for building libphobos,
 which are linked in during compilation of libgphobos.so


I seem to be getting a lot of these with the latest build trying to build a
windows project (Daniel: the same repo I referred to in that bug report)

c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.6.1/../../../../lib32/libgphobos2.a(ti_Aint.o):
In function `rt.typeinfo.ti_Aint._D2rt8typeinfo7ti_Aint9__modinitFZv':
C:\crossdev\gdc64\v2\build\x86_64-w64-mingw32\32\libphobos\libdruntime/../../../../../gcc-4.6.1/libphobos/libdruntime/rt/typeinfo/ti_Aint.d:1:
undefined reference to `_Dmodule_ref'
C:\crossdev\gdc64\v2\build\x86_64-w64-mingw32\32\libphobos\libdruntime/../../../../../gcc-4.6.1/libphobos/libdruntime/rt/typeinfo/ti_Aint.d:1:
undefined reference to `_Dmodule_ref'
c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.6.1/../../../../lib32/libgphobos2.a(conv.o):
In function `std.conv._D3std4conv9__modinitFZv':
C:\crossdev\gdc64\v2\build\x86_64-w64-mingw32\32\libphobos/../../../../gcc-4.6.1/libphobos/std/conv.d:1:
undefined reference to `_Dmodule_ref'
C:\crossdev\gdc64\v2\build\x86_64-w64-mingw32\32\libphobos/../../../../gcc-4.6.1/libphobos/std/conv.d:1:
undefined reference to `_Dmodule_ref'
etc...


I also built sqlite, but it's complaining with lots of:

C:\Users\MANUEV~1\AppData\Local\Temp\cclkNCic.o: In function
`D4demu5tools8sqlitedb8SQLiteDB6AttachMFAxaAxaZE4demu5tools5error9ErrorCode':
D:\Projects\SuperEmu/Source/Tools/SQLiteDB.d:57: undefined reference to
`sqlite3_exec'
C:\Users\MANUEV~1\AppData\Local\Temp\cclkNCic.o: In function
`D4demu5tools8sqlitedb8SQLiteDB5CloseMFZv':
D:\Projects\SuperEmu/Source/Tools/SQLiteDB.d:46: undefined reference to
`sqlite3_close'
C:\Users\MANUEV~1\AppData\Local\Temp\cclkNCic.o: In function
`D4demu5tools8sqlitedb8SQLiteDB4OpenMFAxaZE4demu5tools5error9ErrorCode':
D:\Projects\SuperEmu/Source/Tools/SQLiteDB.d:34: undefined reference to
`sqlite3_open'
etc...


Any ideas?

Here's how I built sqlite, in case I did something wrong:
gcc -c sqlite3.c -m64 -O3  -> sqlite3.o
ar rs libsqlite.a sqlite3.o    -> sqlite.a
Apr 30 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
On 30 April 2012 18:33, Daniel Green <venix1 gmail.com> wrote:


 sqlite.o is easy enough to build and can be put into libgphobos.a. Being
 public domain helps, I'll add it to the build process.


libsqlite is quite big, perhaps it would be better to have the script
create a lib beside phobos instead of in it?
DMD supplies this as a separate lib, although theirs is about 1/3rd the
size of the one I built for some reason :/


Curl is the only tricky one.  It actually has configuration options and

 probably dependencies.  Is there a list of what features D requires curl to
 support?



I suspect the doc may reveal which features are available:
http://dlang.org/phobos/etc_c_curl.html (looks like it covers basically
everything)
Is there a standard set of features for some 'standard' binary
distribution? Most linux '-dev' packages seem to include binary libs for
easy access, there must be a standard used there...

I had trouble building curl, but I will be using all 3 currently existing
etc.c libs in my app.
Apr 30 2012
prev sibling parent reply Manu <turkeyman gmail.com> writes:
On 30 April 2012 21:24, Manu <turkeyman gmail.com> wrote:

 I seem to be getting a lot of these with the latest build trying to build
 a windows project (Daniel: the same repo I referred to in that bug report)

 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.6.1/../../../../lib32/libgphobos2.a(ti_Aint.o):
 In function `rt.typeinfo.ti_Aint._D2rt8typeinfo7ti_Aint9__modinitFZv':
 C:\crossdev\gdc64\v2\build\x86_64-w64-mingw32\32\libphobos\libdruntime/../../../../../gcc-4.6.1/libphobos/libdruntime/rt/typeinfo/ti_Aint.d:1:
 undefined reference to `_Dmodule_ref'
 C:\crossdev\gdc64\v2\build\x86_64-w64-mingw32\32\libphobos\libdruntime/../../../../../gcc-4.6.1/libphobos/libdruntime/rt/typeinfo/ti_Aint.d:1:
 undefined reference to `_Dmodule_ref'
 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.6.1/../../../../lib32/libgphobos2.a(conv.o):
 In function `std.conv._D3std4conv9__modinitFZv':
 C:\crossdev\gdc64\v2\build\x86_64-w64-mingw32\32\libphobos/../../../../gcc-4.6.1/libphobos/std/conv.d:1:
 undefined reference to `_Dmodule_ref'
 C:\crossdev\gdc64\v2\build\x86_64-w64-mingw32\32\libphobos/../../../../gcc-4.6.1/libphobos/std/conv.d:1:
 undefined reference to `_Dmodule_ref'
 etc...


 I also built sqlite, but it's complaining with lots of:

 C:\Users\MANUEV~1\AppData\Local\Temp\cclkNCic.o: In function
 `D4demu5tools8sqlitedb8SQLiteDB6AttachMFAxaAxaZE4demu5tools5error9ErrorCode':
 D:\Projects\SuperEmu/Source/Tools/SQLiteDB.d:57: undefined reference to
 `sqlite3_exec'
 C:\Users\MANUEV~1\AppData\Local\Temp\cclkNCic.o: In function
 `D4demu5tools8sqlitedb8SQLiteDB5CloseMFZv':
 D:\Projects\SuperEmu/Source/Tools/SQLiteDB.d:46: undefined reference to
 `sqlite3_close'
 C:\Users\MANUEV~1\AppData\Local\Temp\cclkNCic.o: In function
 `D4demu5tools8sqlitedb8SQLiteDB4OpenMFAxaZE4demu5tools5error9ErrorCode':
 D:\Projects\SuperEmu/Source/Tools/SQLiteDB.d:34: undefined reference to
 `sqlite3_open'
 etc...


 Any ideas?

 Here's how I built sqlite, in case I did something wrong:
 gcc -c sqlite3.c -m64 -O3  -> sqlite3.o
 ar rs libsqlite.a sqlite3.o    -> sqlite.a


Actually, I just tried -m64 and the _Dmodule_ref errors were all gone...
switched back to -m32 and they were back again...
User error? What are they about?
Apr 30 2012
parent reply Daniel Green <venix1 gmail.com> writes:
On 4/30/2012 2:49 PM, Manu wrote:

     I also built sqlite, but it's complaining with lots of:

     C:\Users\MANUEV~1\AppData\Local\Temp\cclkNCic.o: In function
     `D4demu5tools8sqlitedb8SQLiteDB6AttachMFAxaAxaZE4demu5tools5error9ErrorCode':
     D:\Projects\SuperEmu/Source/Tools/SQLiteDB.d:57: undefined reference
     to `sqlite3_exec'
     C:\Users\MANUEV~1\AppData\Local\Temp\cclkNCic.o: In function
     `D4demu5tools8sqlitedb8SQLiteDB5CloseMFZv':
     D:\Projects\SuperEmu/Source/Tools/SQLiteDB.d:46: undefined reference
     to `sqlite3_close'
     C:\Users\MANUEV~1\AppData\Local\Temp\cclkNCic.o: In function
     `D4demu5tools8sqlitedb8SQLiteDB4OpenMFAxaZE4demu5tools5error9ErrorCode':
     D:\Projects\SuperEmu/Source/Tools/SQLiteDB.d:34: undefined reference
     to `sqlite3_open'
     etc...


     Any ideas?


Build order?  binutils isn't smart(purposefully so?) when it comes to 
symbol resolution.  The symbol must be declared after it is used.  I 
would check the -v output and see where your library is in relation to 
the object file.


     Here's how I built sqlite, in case I did something wrong:
     gcc -c sqlite3.c -m64 -O3  -> sqlite3.o
     ar rs libsqlite.a sqlite3.o    -> sqlite.a


This would save you the need to add -lsqlite and ensure that phobos 
symbols are properly resolved as well.  As Iain suggested, this may be 
what GDC will start doing.

ar q libgphobos2.a sqlite3.o

Here's the size with -O2, -O3 for 32 and 64 bit.
-rw-r--r-- 1 venix Administrators 742K Apr 30 23:23 sqlite3-m32-03.
-rw-r--r-- 1 venix Administrators 565K Apr 30 23:21 sqlite3-m32.o
-rw-r--r-- 1 venix Administrators 755K Apr 30 23:30 sqlite3-m64-03.
-rw-r--r-- 1 venix Administrators 579K Apr 30 23:32 sqlite3-m64.o


 Actually, I just tried -m64 and the _Dmodule_ref errors were all gone...
 switched back to -m32 and they were back again...
 User error? What are they about?


DMD/Windows uses minit for module initialization.  GDC uses 
_Dmodule_ref.  In the last release, they reorganized some module 
initialization code causing GDC/MinGW to not use define/use _Dmodule_ref 
initialization.

Currently, there is an issue with multilib building on MinGW.  I had to 
manually compile and extract libphobos for the release.  It's possible I 
missed something.
Apr 30 2012
parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 1 May 2012 05:37, Daniel Green <venix1 gmail.com> wrote:

 On 4/30/2012 2:49 PM, Manu wrote:

 =A0 =A0I also built sqlite, but it's complaining with lots of:

 =A0 =A0C:\Users\MANUEV~1\AppData\Local\Temp\cclkNCic.o: In function

 =A0`D4demu5tools8sqlitedb8SQLiteDB6AttachMFAxaAxaZE4demu5tools5error9Err=




orCode':

 =A0 =A0D:\Projects\SuperEmu/Source/Tools/SQLiteDB.d:57: undefined refere=




nce

 =A0 =A0to `sqlite3_exec'
 =A0 =A0C:\Users\MANUEV~1\AppData\Local\Temp\cclkNCic.o: In function
 =A0 =A0`D4demu5tools8sqlitedb8SQLiteDB5CloseMFZv':
 =A0 =A0D:\Projects\SuperEmu/Source/Tools/SQLiteDB.d:46: undefined refere=




nce

 =A0 =A0to `sqlite3_close'
 =A0 =A0C:\Users\MANUEV~1\AppData\Local\Temp\cclkNCic.o: In function

 =A0`D4demu5tools8sqlitedb8SQLiteDB4OpenMFAxaZE4demu5tools5error9ErrorCod=




e':

 =A0 =A0D:\Projects\SuperEmu/Source/Tools/SQLiteDB.d:34: undefined refere=




nce

 =A0 =A0to `sqlite3_open'
 =A0 =A0etc...


 =A0 =A0Any ideas?



 Build order? =A0binutils isn't smart(purposefully so?) when it comes to s=


ymbol

 resolution. =A0The symbol must be declared after it is used. =A0I would c=


heck

 the -v output and see where your library is in relation to the object fil=


e.

 =A0 =A0Here's how I built sqlite, in case I did something wrong:
 =A0 =A0gcc -c sqlite3.c -m64 -O3 =A0-> sqlite3.o
 =A0 =A0ar rs libsqlite.a sqlite3.o =A0 =A0-> sqlite.a



 This would save you the need to add -lsqlite and ensure that phobos symbo=


ls

 are properly resolved as well. =A0As Iain suggested, this may be what GDC=


 will

 start doing.

 ar q libgphobos2.a sqlite3.o

 Here's the size with -O2, -O3 for 32 and 64 bit.
 -rw-r--r-- 1 venix Administrators 742K Apr 30 23:23 sqlite3-m32-03.
 -rw-r--r-- 1 venix Administrators 565K Apr 30 23:21 sqlite3-m32.o
 -rw-r--r-- 1 venix Administrators 755K Apr 30 23:30 sqlite3-m64-03.
 -rw-r--r-- 1 venix Administrators 579K Apr 30 23:32 sqlite3-m64.o



 Actually, I just tried -m64 and the _Dmodule_ref errors were all gone...
 switched back to -m32 and they were back again...
 User error? What are they about?


 DMD/Windows uses minit for module initialization. =A0GDC uses _Dmodule_re=


f.

 =A0In the last release, they reorganized some module initialization code
 causing GDC/MinGW to not use define/use _Dmodule_ref initialization.

 Currently, there is an issue with multilib building on MinGW. =A0I had to
 manually compile and extract libphobos for the release. =A0It's possible =


I

 missed something.


no _Dmodule_ref would probably mean no object_.d was compiled in.


--=20
Iain Buclaw

*(p < e ? p++ : p) =3D (c & 0x0f) + '0';
Apr 30 2012
parent reply Daniel Green <venix1 gmail.com> writes:
On 5/1/2012 1:53 AM, Iain Buclaw wrote:

 no _Dmodule_ref would probably mean no object_.d was compiled in.


In D2.058, the _Dmodule_ref code was moved to minfo.d.  I didn't 
properly move the GNU specific stuff on the first build, problem didn't 
surface until I compiled it with MinGW.

They reduced it to OSX, Posix for including _Dmodule_ref.  Which is why 
linux didn't exhibit the same problems.

I added it back but there's a chance the 32-bit library wasn't updated 
properly.
May 01 2012
parent Manu <turkeyman gmail.com> writes:
On 1 May 2012 17:31, Daniel Green <venix1 gmail.com> wrote:


 On 5/1/2012 1:53 AM, Iain Buclaw wrote:


 no _Dmodule_ref would probably mean no object_.d was compiled in.


 In D2.058, the _Dmodule_ref code was moved to minfo.d.  I didn't properly
 move the GNU specific stuff on the first build, problem didn't surface
 until I compiled it with MinGW.

 They reduced it to OSX, Posix for including _Dmodule_ref.  Which is why
 linux didn't exhibit the same problems.

 I added it back but there's a chance the 32-bit library wasn't updated
 properly.


No problem, I only depend on x64 for the time being, so it's no problem to
use that :)
May 01 2012