mtholder.github.io/home/

Jeet and I tracked this down after I was having issues compiling RevBayes , while it was working for him. It turns out that CMake was including compiler flags for me that it was not including for him (fwiw: I compiled cmake, Jeet used a pre-built version).

Here is the very odd bit. The code

#include <list>
int main() {
    std::list<int*> x(1, NULL);
}

will compile with a simple g++ t.cpp -arch x86_64 when using i686-apple-darwin10-g++-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3) on a MacBookPro running 10.6.8.

The same code will not compile if you use the using tho -arch i386 flag. The compiler (not linker!) error is:

/usr/include/c++/4.2.1/bits/stl_list.h: In member function 'void std::list<_Tp, _Alloc>::_M_initialize_dispatch(_Integer, _Integer, std::__true_type) [with _Integer = int, _Tp = int*, _Alloc = std::allocator<int*>]':
/usr/include/c++/4.2.1/bits/stl_list.h:515:   instantiated from 'std::list<_Tp, _Alloc>::list(_InputIterator, _InputIterator, const _Alloc&) [with _InputIterator = int, _Tp = int*, _Alloc = std::allocator<int*>]'
t.cpp:3:   instantiated from here
/usr/include/c++/4.2.1/bits/stl_list.h:1105: error: invalid static_cast from type 'int' to type 'int*'

Pre-processing the file (with g++'s -e option) reveals that the dreaded NULL macro gets expanded to __null

It appears that __null is an int version of 0 when you compile for i386, but a long in the 64-bit version; and the implicit cast from int to a pointer type is causing the problem. That is ugly.

I tried to report this via apple's bug report system, but a bug in that system made it impossible for me to log-in. Nice. Everything must be working great - we are getting no bug reports!