Ok, I found the source of the problem, and I'm amazed that there were no indications or warnings, that "poor soul, who shall follow this path take care, for there be many undocumented pitfalls down the road".
First of all: I still think it is funny that the linux samples contain functions, which are nowhere explained, neither they are defined in the code. Me, as an unexperienced programmer in terms of XLib, all I can do is to comment out these functions and hope for the best. I tried looking for functions in XLib that might implement something similar, but found nothing. (might be my fault)
Second: Perhaps some indication to the mandatorial use of GLEWmx, and the HEAPS AND HEAPS of troubles that come with it would've been appreciated. Namely the fact that if one wishes to initialize multiple devices in this manner, they'll have to implement a global GLEW and GLXEW/WGLEW context manager, otherwise hell breaks loose.
So to answer my initial question, why the sample code breaks and why it is a real pain to do things the multi-GPU way... glX functions need glxewInit() to be called so that these function pointers to the extensions of the windowing system (similarily to glewInit() to simple OpenGL extensions) are initalized. Without this, naturally garbage pointers will be dereferenced. The issue is that glxewInit() (just as glewInit()) can only be called once there is an active OpenGL context. (Yet again the problem of the yeti and the egg) Some sample codes deal with this by creating a default, (low-version) dummy OpenGL context, call Init() functions, throw away the dummy context, and start fresh. Other sample codes load the function pointers manually using glXGetProcAddressARB.
I truly appreciate the samples given in the programming guide, it'w a rarity that such functionality comes with samples, but the person who wrote it knew about all this **** all along. Doesn't all this hassle cry for 2 lines in a "Note: beware..."
