Build Failure: using cmake

[ghost]

Hi, I am trying to use the new cmake build system and I have encountered this error when I was using ninja check-pyston:

In file included from /home/bobfang/pyston/src/codegen/ast_interpreter.cpp:35:
In file included from /home/bobfang/pyston/src/runtime/generator.h:19:
/home/bobfang/pyston/src/runtime/types.h:247:1: error: static_assert failed ""
static_assert(offsetof(pyston::BoxedClass, base) == offsetof(struct _typeobject, _base), "");
^             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/bobfang/pyston/src/runtime/types.h:248:1: error: static_assert failed ""
static_assert(offsetof(pyston::BoxedClass, gc_visit) == offsetof(struct _typeobject, _gcvisit_func), "");
^             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/bobfang/pyston/src/runtime/types.h:249:1: error: static_assert failed ""
static_assert(sizeof(pyston::BoxedClass) == sizeof(struct _typeobject), "");
^             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/bobfang/pyston/src/runtime/types.h:251:1: error: static_assert failed ""
static_assert(offsetof(pyston::BoxedHeapClass, base) == offsetof(PyHeapTypeObject, ht_type._base), "");
^             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/bobfang/pyston/src/runtime/types.h:252:1: error: static_assert failed ""
static_assert(offsetof(pyston::BoxedHeapClass, as_number) == offsetof(PyHeapTypeObject, as_number), "");
^             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/bobfang/pyston/src/runtime/types.h:253:1: error: static_assert failed ""
static_assert(offsetof(pyston::BoxedHeapClass, as_mapping) == offsetof(PyHeapTypeObject, as_mapping), "");
^             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/bobfang/pyston/src/runtime/types.h:254:1: error: static_assert failed ""
static_assert(offsetof(pyston::BoxedHeapClass, as_sequence) == offsetof(PyHeapTypeObject, as_sequence), "");
^             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/bobfang/pyston/src/runtime/types.h:255:1: error: static_assert failed ""
static_assert(offsetof(pyston::BoxedHeapClass, as_buffer) == offsetof(PyHeapTypeObject, as_buffer), "");
^             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/bobfang/pyston/src/runtime/types.h:256:1: error: static_assert failed ""
static_assert(sizeof(pyston::BoxedHeapClass) == sizeof(PyHeapTypeObject), "");
^             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
9 errors generated.

Do you know how can I fix this without messing up the source files?

[undingen]

I haven't tried building pyston recently but I'm familiar with similar error messages when the libstd++ from gcc 4.9 is used (e.g. ubuntu 14.10). What version of gcc do you have installed on your system?

[ghost]

gcc version 4.9.1 (Ubuntu 4.9.1-16ubuntu6)

[undingen]

you asked for a solution without messing with the source but I don't have one, instead I may have a temporary workaround until there is a configure script: change in include/object.h char _dep_getattrs[56]; to char _dep_getattrs[56 + 8];. I haven't tried it recently but this worked few days ago.

[ghost]

I tried to set my gcc to gcc-4.8 and it does not work either, so I guess it is not gcc-4.9's fault.

[ghost]

Also your solution works :+1:

[undingen]

I think it's even clang which is complaining: it's picking up the newest libstdc++ and there AFAIK unordered_map has a slightly different size.

Later I will try to check the version with the __GLIBCXX__ macro for a fix which does not require a configure script.

[dagar]

I can look into getting the size with cmake at configure time. Alternatively, why not just use sizeof within Pyston?

[undingen]

The problem is that we need to know the size C extension module headers. That's why we can't use sizeof our c++ class or the class directly because a C compiler must understand it. The same problem exists with the GLIBCXX define which will only be set when the libstdc++ is included.