Date: Thu, 15 Sep 2011 15:58:45 -0600 From: John Hein <jhein@symmetricom.com> To: Mark Linimon <linimon@lonesome.com> Cc: bf1783@gmail.com, freebsd-x11@FreeBSD.org, freebsd-sparc64@FreeBSD.org Subject: Re: anybody have an idea of what is breaking on libGLU on sparc64? Message-ID: <20082.29973.769349.357297@duck.timing.com> In-Reply-To: <20110915212958.GA29839@lonesome.com> References: <CAGFTUwNHqe0fiX_iGjXYFEsR2CiaL1dXo%2BPHnfFdHMjNkvtvdg@mail.gmail.com> <20110915212958.GA29839@lonesome.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20082.29973.769349.357297>