** 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

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

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
>

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?

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

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

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

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.

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?

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.

On 1 May 2012 05:37, Daniel Green <venix1@gmail.com> wrote:
> 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.

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


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';