> When building the Mesa library with the gcc bundled
> with Solaris,
> I get a fatal ld error of the form:
>
> ld: fatal: relocation error: R_386_GOTOFF: file
> indirect_init.o: symbol
> __indirect_glNewList: relocation must bind locally
>
> Googling for this error suggests that the fix in
> other projects has been
> to disable gcc's symbol visibility attributes on
> Solaris, but that doesn't
> seem to help here. Any suggestions for how to fix?
>
> The header file defines the function as:
> # define HIDDEN
> __attribute__((visibility("hidden")))
> ..]
> extern HIDDEN void __indirect_glNewList(GLuint list,
> GLenum mode);
>
> The definition in indirect.c looks like:
> void
> __indirect_glNewList(GLuint list, GLenum mode)
> {
> [...]
> }
>
> The reference in indirect_init.c uses it as a
> function pointer, not
> a direct call:
>
> glAPI->NewList = __indirect_glNewList;
> lfdump indirect.o | grep glNewList:
>
> [34] 0x00000720 0x00000068 FUNC GLOB D 0
> .text
> __indirect_glNewList
>
> % elfdump
> build_32/Mesa-6.5.1/src/glx/x11/indirect_init.o |
> grep glNewList
> [11] 0x00000000 0x00000000 NOTY GLOB D 0
> UNDEF
> __indirect_glNewList
> R_386_GOTOFF 0x5a
> .rel.text
> NewList
>
> Any suggestions? Anyone able to translate the error
> message into something
> understandable by those without the ELF spec
> memorized?
>
> --
> -Alan Coopersmith-
> - alan dot coopersmith at sun dot com
> Sun Microsystems, Inc. - X Window Systemem EngineeringOnly a few lines, I instantly have to go. Concerning mesa-libs and userland _dri.so drivers: I now get (almost) the full lib/mesa tree built, including most _dri.so userland drivers. However, as I now use gcc for mesa-libs, I would have had the same problem as you had on x86 last November (see above), if I had not used your ./sun-src/src/glx/x11/mapfile.scope. I also get circa 750 (per build_[32|64] dir) of those warnings: indirect.c: In function `__indirect_glNewList': indirect.c:319: warning: visibility attribute not supported in this configuration; ignored but thanks to your mapfile.scope file the build does succeed. Unfortunately did a related issue come into existance, after I switched to gcc for mesa-libs, rather than continuing to use SUNWspro-cc (which has other drawbacks in terms of mesa-libs): Now the mesa-demos don't link against libGL*.so.* anymore. I get unresolved symbols ld errors, as if the local-directives from your mapfile.scope were not truly in effect, that is, as if all those symbols still got exported globally: cc -I../../include -KPIC -O -I/usr/openwin/include -I/usr/dt/include -DUSE_XSHM -DPTHREADS glxgears.c -L/usr/X11/lib -lX11 -lGLw -lGLU -lGL -lm -o glxgears Undefined first referenced symbol in file glEnd glxgears.o glBitmap /usr/X11/lib/libGL.so _glapi_get_dispatch /usr/X11/lib/libGL.so glEnable glxgears.o glTexCoord2f /usr/X11/lib/libGLU.so glFinish /usr/X11/lib/libGL.so glScalef /usr/X11/lib/libGLU.so _glapi_Dispatch /usr/X11/lib/libGL.so glLightfv glxgears.o glTranslated glxgears.o glTranslatef glxgears.o sunOglCurPrimTablePtr glxgears.o _glapi_set_dispatch /usr/X11/lib/libGL.so glPolygonMode /usr/X11/lib/libGLU.so glMapGrid2d /usr/X11/lib/libGLU.so glMapGrid2f /usr/X11/lib/libGLU.so glMapGrid1f /usr/X11/lib/libGLU.so glDeleteLists glxgears.o glNewList glxgears.o glPopAttrib /usr/X11/lib/libGLU.so glPopMatrix glxgears.o glNormal3f /usr/X11/lib/libGLU.so _glapi_get_proc_address /usr/X11/lib/libGL.so glEvalPoint1 /usr/X11/lib/libGLU.so glEvalPoint2 /usr/X11/lib/libGLU.so glCallList glxgears.o glEvalCoord1f /usr/X11/lib/libGLU.so glEvalCoord2f /usr/X11/lib/libGLU.so glEvalMesh1 /usr/X11/lib/libGLU.so glEvalMesh2 /usr/X11/lib/libGLU.so glGetFloatv /usr/X11/lib/libGLU.so glNormal3fv /usr/X11/lib/libGLU.so glRotatef glxgears.o glVertex2fv /usr/X11/lib/libGLU.so glVertex3fv /usr/X11/lib/libGLU.so glGetString glxgears.o glColor3f /usr/X11/lib/libGLU.so glPushAttrib /usr/X11/lib/libGLU.so glMaterialfv glxgears.o _glapi_check_multithread /usr/X11/lib/libGL.so glTexImage1D /usr/X11/lib/libGLU.so glTexImage2D /usr/X11/lib/libGLU.so glTexImage3D /usr/X11/lib/libGLU.so sunOglCurrentContext glxgears.o glDisable /usr/X11/lib/libGLU.so glLoadIdentity glxgears.o glGetIntegerv glxgears.o glPushMatrix glxgears.o glGetTexLevelParameteriv /usr/X11/lib/libGLU.so glGenLists glxgears.o glEndList glxgears.o glShadeModel glxgears.o glVertex2f /usr/X11/lib/libGLU.so glVertex3f /usr/X11/lib/libGLU.so glDrawBuffer glxgears.o glFrustum glxgears.o glMultMatrixd /usr/X11/lib/libGLU.so glMultMatrixf /usr/X11/lib/libGLU.so glBegin glxgears.o glClear glxgears.o glMap1f /usr/X11/lib/libGLU.so glMap2f /usr/X11/lib/libGLU.so glOrtho /usr/X11/lib/libGLU.so _glapi_get_dispatch_table_size /usr/X11/lib/libGL.so glPixelStorei /usr/X11/lib/libGLU.so glViewport glxgears.o glMatrixMode glxgears.o ld: fatal: Symbol referencing errors. No output written to glxgears *** Error code 1 make: Warning: Target `glxgears' not remade because of errors Current working directory /FOX/MERCURIAL_20070830thu/XXX__fox-gate/XW_NV/open-src/app/mesa-demos/build_32 /Mesa-6.5.2/progs/xdemos *** Error code 1 With cc built mesa-libs it would just work (etc. etc. etc., no time). It needs further investigation, but I'm away for 5 hours. I just got an idea, maybe mesa-libs and mesa-demos need to be built with the *same* compiler, rather than using gcc for mesa-libs and cc for mesa-demos? Might that make sense. Any hints would be thankfully appreciated. Further status updates: # merge almost ready for pushing current snapshot. # xsvc builds for sparc now, but doesn't work yet (so we cannot yet replace aperture) # drm kernel module now successfully modload's and add_drv's on SPARC. But the device specific kernel modules are more problematic because they depend on vgatext-symbols/functionality (which will probably never work on non-x86 platforms, vga). The device specific drm kernel modules need adjustment to SPARC's /dev/fb driver api. 'back in 5 hours. -- -Martin Bochnig- bochnig at pool dot math dot tu-berlin dot de MartUX, Inc. - random FOX/Xorg, QEMU, MartUX Engineering This message posted from opensolaris.org
