www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - FreeBSD 6 amd64 tweak: Compiling problem: CLASSINFO_SIZE assert

reply Sean Chittenden <sean arcscale.com> writes:
Howdy.  I'm on an amd64 FreeBSD 6.2-rc machine and have been able to get it to
compile on FreeBSD6 amd64 with the following
patches.  I haven't conditionalized them inside of the build infrastructure,
but am going to likely incorporate them into
my port upgrade to 0.21.  The problem is described below:

/usr/ports/lang/gdc/work/build/gcc/gdc -B/usr/ports/lang/gdc/work/build/gcc/
-B/usr/local/x86_64-portbld-freebsd6.2/bin/
-B/usr/local/x86_64-portbld-freebsd6.2/lib/ -isystem
/usr/local/x86_64-portbld-freebsd6.2/include -isystem
/usr/local/x86_64-portbld-freebsd6.2/sys-include -o
std/loader.o -g -frelease -O2  -fversion=GC_Use_Alloc_MMap
-fversion=GC_Use_Stack_FreeBSD -fversion=GC_Use_Data_Fixed -nostdinc -I
../.././../gcc-4.0-20061228/libphobos -I
../.././../gcc-4.0-20061228/libphobos/internal/gc -I
./x86_64-portbld-freebsd6.2 -c
../.././../gcc-4.0-20061228/libphobos/std/loader.d
Assertion failed: (classinfo->structsize == CLASSINFO_SIZE), function toObjFile,
file .././../gcc-4.0-20061228/gcc/d/dmd/toobj.c, line 416.
../.././../gcc-4.0-20061228/libphobos/std/loader.d:428: internal compiler
error: Abort trap: 6
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
gmake: *** [std/loader.o] Error 1
Exit 2

Line 416 is the assert shown below:
    /* The layout is:
       {
            void **vptr;
            monitor_t monitor;
            byte[] initializer;         // static initialization data
            char[] name;                // class name
            void *[] vtbl;
            Interface[] interfaces;
            ClassInfo *base;            // base class
            void *destructor;
            void *invariant;            // class invariant
            uint flags;
            void *deallocator;
       }
     */
    dt_t *dt = NULL;
    offset = CLASSINFO_SIZE;                    // must be ClassInfo.size
    if (classinfo)
    {
        assert(classinfo->structsize == CLASSINFO_SIZE); // line 416
    }

The '#define CLASSINFO_SIZE 0x3C' line in d/dmd/aggregate.h for amd64 should be
0x70.  Is CLASSINFO_SIZE being set for a
32bit arch vs a 64bit arch?  Where is the classinfo struct being defined? 
Can't some sizeof() work fix this?  I also tried
commenting out the assert and replacing it with some printf()'s to see if the
#define wasn't set correctly for an x64
system, but I didn't have any luck finding the dependencies and had to patch,
then completely recompile.  What's the trick
here?

I'm still working through porting, however....

/usr/ports/lang/gdc/work/build/gcc/gdc -B/usr/ports/lang/gdc/work/build/gcc/
-B/usr/local/x86_64-portbld-freebsd6.2/bin/
-B/usr/local/x86_64-portbld-freebsd6.2/lib/ -isystem
/usr/local/x86_64-portbld-freebsd6.2/include -isystem
/usr/local/x86_64-portbld-freebsd6.2/sys-include -o
std/format.o -g -frelease -O2  -fversion=GC_Use_Alloc_MMap
-fversion=GC_Use_Stack_FreeBSD -fversion=GC_Use_Data_Fixed -nostdinc -I
../.././../gcc-4.0-20061228/libphobos -I
../.././../gcc-4.0-20061228/libphobos/internal/gc -I
./x86_64-portbld-freebsd6.2 -c
../.././../gcc-4.0-20061228/libphobos/std/format.d
../.././../gcc-4.0-20061228/libphobos/std/format.d:837: static assert  (0) is
false, "uimplemented"
gmake[1]: *** [std/format.o] Error 1
gmake[1]: Leaving directory
`/usr/ports/lang/gdc/work/build/x86_64-portbld-freebsd6.2/libphobos'
gmake: *** [all-target-libphobos] Error 2
*** Error code 2

-sc
Jan 07 2007
parent reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sean Chittenden schrieb am 2007-01-07:
 Howdy.  I'm on an amd64 FreeBSD 6.2-rc machine and have been able to get it to
compile on FreeBSD6 amd64 with the following
 patches.  I haven't conditionalized them inside of the build infrastructure,
but am going to likely incorporate them into
 my port upgrade to 0.21.  The problem is described below:

The mainline GDC can currently only produce object code for 32bit targets. Personally I'm using a 64bit GDC binary to compile for i686: http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=D.gnu&artnum=1879 Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFFoWsMLK5blCcjpWoRAkZjAKCojP/L91SfzcouA+toBjczCwJcTgCfQ54B qUhpSK3ZC2wBKT/j61ycpIc= =UqLj -----END PGP SIGNATURE-----
Jan 07 2007
parent reply Sean Chittenden <sean arcscale.com> writes:
== Quote from Thomas Kuehne (thomas-dloop kuehne.cn)'s article
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 Sean Chittenden schrieb am 2007-01-07:
 Howdy.  I'm on an amd64 FreeBSD 6.2-rc machine and have been able to get it to
compile on FreeBSD6 amd64 with the


 patches.  I haven't conditionalized them inside of the build infrastructure,
but am going to likely incorporate them


 my port upgrade to 0.21.  The problem is described below:

targets. Personally I'm using a 64bit GDC binary to compile for i686: http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=D.gnu&artnum=1879

... but... I don't have any 32bit machines anymore, anywhere! :~] I'll see if I can dig up some extra boxes that I can reformat and mash on. If you had to give a thumbnail guess as to what needed to be done to get X86_64 finished or what the timeframe is on that, would/could you? I was searching around and didn't find anything that hinted at where it was on the road map. If I comment out the assert() in format.d, it finishes compiling successfully, however it fails to link object code. % gdc hello.d /usr/local/lib/libgphobos.a(outofmemory.o)(.rodata+0x18):../.././../gcc-4.0-20061228/libphobos/std/outofmemory.d:26: undefined reference to `_D6object6Object6toHashMFZk' /usr/local/lib/libgphobos.a(moduleinit.o)(.rodata+0x38):../.././../gcc-4.0-20061228/libphobos/std/moduleinit.d:44: undefined reference to `_D6object6Object6toHashMFZk' /usr/local/lib/libgphobos.a(moduleinit.o)(.rodata+0x98):../.././../gcc-4.0-20061228/libphobos/std/moduleinit.d:44: undefined reference to `_D6object6Object6toHashMFZk' /usr/local/lib/libgphobos.a(string.o)(.rodata+0x18):../.././../gcc-4.0-20061228/libpho os/std/string.d:64: undefined reference to `_D6object6Object6toHashMFZk' /usr/local/lib/libgphobos.a(array.o)(.rodata+0x18):../.././../gcc-4.0-20061228/libph bos/std/array.d:14: undefined reference to `_D6object6Object6toHashMFZk' /usr/local/lib/libgphobos.a(utf.o)(.rodata+0x18):../.././../gcc-4.0-20061228/lib hobos/std/utf.d:57: more undefined references to `_D6object6Object6toHashMFZk' follow Exit 1 Similarly, the make check craps out with something similar: % make check gmake[1]: Entering directory `/usr/ports/lang/gdc/work/build/x86_64-portbld-freebsd6.2/libphobos' /usr/ports/lang/gdc/work/build/gcc/gdc -B/usr/ports/lang/gdc/work/build/gcc/ -B/usr/local/x86_64-portbld-freebsd6.2/bin/ -B/usr/local/x86_64-portbld-freebsd6.2/lib/ -isystem /usr/local/x86_64-portbld-freebsd6.2/include -isystem /usr/local/x86_64-portbld-freebsd6.2/sys-include -o unittest -O2 -O2 -fno-strict-aliasing -pipe -march=k8 unittest.o -L./ -lgphobos_t -lm -lc_r unittest.o(.data+0xf8): In function `_Dmain': ../.././../gcc-4.0-20061228/libphobos/unittest.d:66: undefined reference to `_D3std5boxer12__ModuleInfoZ' .//libgphobos_t.a(outofmemory.t.o)(.rodata+0x18):../.././../gcc-4.0-20061228/libphobos/s d/outofmemory.d:26: undefined reference to `_D6object6Object6toHashMFZk' .//libgphobos_t.a(file.t.o)(.rodata+0x58):../.././../gcc-4.0-20061228/libph bos/std/file.d:874: undefined reference to `_D6object6Object6toHashMFZk' .//libgphobos_t.a(moduleinit.t.o)(.rodata+0x38):../.././../gcc-4.0-20061228/libphobos/ td/moduleinit.d:44: undefined reference to `_D6object6Object6toHashMFZk' .//libgphobos_t.a(moduleinit.t.o)(.rodata+0x98):../.././../gcc-4.0-20061228/libphobos/ td/moduleinit.d:44: undefined reference to `_D6object6Object6toHashMFZk' .//libgphobos_t.a(string.t.o)(.rodata+0x18):../.././../gcc-4.0-20061228/libpho os/std/string.d:64: undefined reference to `_D6object6Object6toHashMFZk' .//libgphobos_t.a(math.t.o)(.rodata+0x118):../.././../gcc-4.0-20061228/libph bos/std/math.d:151: more undefined references to `_D6object6Object6toHashMFZk' follow collect2: ld returned 1 exit status gmake[1]: *** [unittest] Error 1 gmake[1]: Leaving directory `/usr/ports/lang/gdc/work/build/x86_64-portbld-freebsd6.2/libphobos' gmake: *** [check-target-libphobos] Error 2 *** Error code 2 Which leaves inquiring minds curious as to if/when or to suck up a 32bit universe for a while. Thanks, I know these are obnoxious questions to have to answer. *grin* -sc
Jan 07 2007
parent Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sean Chittenden schrieb am 2007-01-08:
== Quote from Thomas Kuehne (thomas-dloop kuehne.cn)'s article
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 Sean Chittenden schrieb am 2007-01-07:
 Howdy.  I'm on an amd64 FreeBSD 6.2-rc machine and have been able to get it to
compile on FreeBSD6 amd64 with the


 patches.  I haven't conditionalized them inside of the build infrastructure,
but am going to likely incorporate them


 my port upgrade to 0.21.  The problem is described below:

targets. Personally I'm using a 64bit GDC binary to compile for i686: http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=D.gnu&artnum=1879

... but... I don't have any 32bit machines anymore, anywhere! :~] I'll see if I can dig up some extra boxes that I can reformat and mash on. If you had to give a thumbnail guess as to what needed to be done to get X86_64 finished or what the timeframe is on that, would/could you? I was searching around and didn't find anything that hinted at where it was on the road map. If I comment out the assert() in format.d, it finishes compiling successfully, however it fails to link object code. % gdc hello.d /usr/local/lib/libgphobos.a(outofmemory.o)(.rodata+0x18):../.././../gcc-4.0-20061228/libphobos/std/outofmemory.d:26: undefined reference to `_D6object6Object6toHashMFZk'

That is because object.d seems to be missing or badly mangled: _D6object6Object6toHashMFZk -> uint object.Object.toHash(this) The "uint" above should have been ulong for 64bit systems.
 Which leaves inquiring minds curious as to if/when or to suck up a 32bit
universe for a while.  Thanks, I know these are
 obnoxious questions to have to answer.  *grin*  -sc

That is the beauty with X86_64 systems: they allow running 64bit and 32bit applications side by side. David has said in the past that he wouldn't declare GDC 1.0 before 64 bit were to be implemented. Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFFpf0zLK5blCcjpWoRAmqjAKCE7mLU4EhDZza1WdpPomANtuSNjACfWPHe KjtqY2Z8GRhw9hnqH0y3sJU= =HpyC -----END PGP SIGNATURE-----
Jan 11 2007