Friday, April 14, 2017

Libvirt

Submitted a patch to Red Hat Bugzilla 1442235 to avoid using port 5900, since it conflicts with vino-server. I don't think the patch will be accepted, since the bug was closed as WONTFIX, buit I still think it's the right thing to do.

Benchmark to test later

Geek3D tested an interesting benchmark to evaluate later for 3D acceleration.

GCC / Clang incompatibility

Ran into a problem with ELFE worth sharing, which apparently appeared with the latest clang (in Xcode 8.1). Consider:

struct Base { void *Allocate(); };

template <class T> struct Allocator : Base {
    static T *Allocate();
    static Allocator<T> *singleton;
};

template <class T>
inline T *Allocator<T>::Allocate() {
    return (T *) singleton->Base::Allocate();
}

int main()
{
    int *ptr = Allocator<int>::Allocate();
}

Now this code generates a warning in clang, which frankly I consider pretty bogus:

c++ -c /tmp/glop.cpp
/tmp/glop.cpp:10:18: warning: instantiation of variable
      'Allocator<int>::singleton' required here, but no definition is available
      [-Wundefined-var-template]
    return (T *) singleton->Base::Allocate();
                 ^
/tmp/glop.cpp:15:32: note: in instantiation of member function
      'Allocator<int>::Allocate' requested here
    int *ptr = Allocator<int>::Allocate();
                               ^
/tmp/glop.cpp:5:26: note: forward declaration of template entity is here
    static Allocator<T> *singleton;
                         ^
1 warning generated.

The workaround is to explicitly declare the instantiation:

template <class T>
Allocator<T> *Allocator<T>::singleton;

The problem is that there is a bug in GCC 6.3.1 where this causes it to emit the same symbol multiple times. It should be a weak reference, but it is not, so with GCC this fails at link time. This means that for now, I have to use something like:

#if __clang__ && __clang_major__ >= 8
#endif

around this code. Yuck!