> 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.coopersmith at sun.com
> Sun Microsystems, Inc. - X Window Systemem Engineering
Only 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
