anybody have an idea of what is breaking on libGLU on sparc64?

John Hein jhein at symmetricom.com
Thu Sep 15 22:12:22 UTC 2011


Mark Linimon wrote at 16:29 -0500 on Sep 15, 2011:
 > On Thu, Sep 15, 2011 at 01:00:25PM -0400, b. f. wrote:
 > > Is /usr/local/lib/libGL.so a link pointing to
 > > /usr/local/lib/libGL.so.1?  Is /usr/local/lib/libGL.so.1 corrupted?
 > > Have you tried rebuilding graphics/libGL and then libGLU?
 > 
 > I guess I should have included more of the text common to both files.
 > 
 > >From the sparc64 build:
 > 
 > /bin/sh ../../../bin/mklib -o GL -linker 'cc' -ldflags '-L/usr/local/lib' \
 > 	-major 1 -minor 2  \
 > 	-install ../../../lib -id /usr/local/lib/libGL.1.dylib \
 > 	 -L/usr/local/lib -lXext -lXxf86vm -lXdamage -lXfixes -lX11-xcb -lX11 -lxcb-glx -lxcb   -L/usr/local/lib -ldrm   -lm -lpthread  glcontextmodes.o clientattrib.o compsize.o eval.o glxcmds.o glxcurrent.o glxext.o glxextensions.o indirect.o indirect_init.o indirect_size.o indirect_window_pos.o indirect_texture_compression.o indirect_transpose_matrix.o indirect_vertex_array.o indirect_vertex_program.o pixel.o pixelstore.o render2.o renderpix.o single2.o singlepix.o vertarr.o xfont.o glx_pbuffer.o glx_query.o drisw_glx.o dri_common.o dri_glx.o XF86dri.o glxhash.o dri2_glx.o dri2.o ../../../src/mesa/main/dispatch.o ../../../src/mesa/glapi/glapi.o ../../../src/mesa/glapi/glapi_getproc.o ../../../src/mesa/glapi/glthread.o
 > mklib: Making FreeBSD shared library:  libGL.so.1
 > mklib: Installing libGL.so.1 libGL.so in ../../../lib
 > gmake[2]: Leaving directory `/work/a/ports/graphics/libGLU/work/Mesa-7.4.4/src/glx/x11'
 > gmake[2]: Entering directory `/work/a/ports/graphics/libGLU/work/Mesa-7.4.4/src/mesa'
 > 
 > So it really seems as though it is building a copy of libGL.so for
 > itself?
 > 
 > I can go ahead and try to delete the libGL package as well ...
 > 
 > And yes, I am aware of which line showed the brokenness, the key point
 > I thought was that everything immediately above it was the same for
 > both builds :-)

-L/usr/local/lib precedes -L../../../lib, so it tries to link
with /usr/local/lib/libGL.so.1 rather than the internally
built copy (sparc64 or not). [1]

The question is, I think: why is /usr/local/lib/libGL.so seemingly
invalid (empty?)?  That should have just come from the pkg_add of
dependencies.

[1] So why bother building libGL.so.1 in the working dirs?  But that's
just an build efficiency question.  libGLU.so.1 needs a copy of
libGL.so.1 in /usr/local/lib at run time.



More information about the freebsd-x11 mailing list