On 1 May 2012 05:37, Daniel Green <ven...@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';
