Yes, that's the same:
10260: Test 10425 (shift 2) failed to return proper results. [...]
Here you see the test number for the failing test as well as the source code and the actual output.
Running the test_resolve.pike script directly in gdb shows that it's the GL module that's broken. It's executing glGetIntegerv like this:
#0 0x92da3554 in glGetIntegerv () #1 0x020c9544 in f_glGet () #2 0x065dd96c in ?? () #3 0x0001761c in mega_apply (type=3377, args=-1073753040, arg1=0xbfffcf80, arg2=0x0) at /Users/jonasw/junk/pike/Pike-v7.6-snapshot/src/interpret.c:2006 #4 0x000952b4 in call_pike_initializers (o=0x20ac40, args=1684488) at /Users/jonasw/junk/pike/Pike-v7.6-snapshot/src/object.c:326
...and that symbol is taken from OpenGL.framework:
(gdb) info symbol 0x92da3530 glGetIntegerv in section LC_SEGMENT.__TEXT.__text of /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
Now, the odd thing is that the .so file itself is linked to another GL library, namely the X11R6 dylib:
dark-castle:GL $ otool -L module.so module.so: /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 567.12.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.2.1) /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 18.0.0) /usr/X11R6/lib/libGL.1.dylib (compatibility version 1.2.0, current version 1.2.0) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ /usr/X11R6/lib/libXext.6.dylib (compatibility version 6.4.0, current version 6.4.0) /usr/X11R6/lib/libX11.6.dylib (compatibility version 6.2.0, current version 6.2.0)
Don't know if this mix is the cause of the problem but it does seem strange. Has anyone ever had the GL module working on OS X, and if so was that with or without X11 libraries installed at the same time?