Re: pkg/38503: pkgsrc/graphics/gle fails to build with latest Mesa updates

[Greg Oster <oster%cs.usask.ca@localhost>]

The following reply was made to PR pkg/38503; it has been noted by GNATS.

From: Greg Oster <oster%cs.usask.ca@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: pkg/38503: pkgsrc/graphics/gle fails to build with latest Mesa 
updates 
Date: Thu, 24 Apr 2008 21:48:02 -0600

 bharder writes:
 > >Number:         38503
 > >Category:       pkg
 > >Synopsis:       pkgsrc/graphics/gle fails to build
 > >Confidential:   no
 > >Severity:       serious
 > >Priority:       high
 > >Responsible:    pkg-manager
 > >State:          open
 > >Class:          sw-bug
 > >Submitter-Id:   net
 > >Arrival-Date:   Fri Apr 25 02:30:00 +0000 2008
 > >Originator:     bharder <bharder%methodlogic.net@localhost>
 > >Release:        NetBSD 4.0_STABLE
 > >Organization:
 >      Method Digital Logic (http://www.methodlogic.net)
 > >Environment:
 > System: NetBSD manchester.methodlogic.net 4.0_STABLE NetBSD 4.0_STABLE (manch
 > ester) #29: Tue Apr 22 15:54:00 PDT 2008 
 > root%manchester.methodlogic.net@localhost:/usr
 > /obj/sys/arch/i386/compile/manchester i386
 > Architecture: i386
 > Machine: i386
 > >Description:
 >      A build of pkgsrc/graphics/gle after the glu/glut/Mesa updates from 6->
 > 7 yields:
 > 
 >      # make
 >      [...]
 >      checking if cc supports -c -o file.lo... yes
 >      checking if cc supports -fno-rtti -fno-exceptions... yes
 >      checking whether the linker (/usr/pkgsrc/graphics/gle/work/.wrapper/bin
 > /ld) supports shared libraries... yes
 >      checking how to hardcode library paths into programs... immediate
 >      checking whether stripping libraries is possible... yes
 >      checking dynamic linker characteristics... NetBSD ld.elf_so
 >      checking if libtool supports shared libraries... yes
 >      checking whether to build shared libraries... yes
 >      checking whether to build static libraries... yes
 >      checking whether -lc should be explicitly linked in... yes
 >      creating libtool
 >      checking for strerror in -lcposix... no
 >      checking whether make sets $(MAKE)... (cached) yes
 >      checking for ANSI C header files... (cached) yes
 >      checking for memcpy... yes
 >      checking for X... libraries , headers
 >      checking for gethostbyname... yes
 >      checking for connect... yes
 >      checking for remove... yes
 >      checking for shmat... yes
 >      checking for IceConnectionNumber in -lICE... yes
 >      checking for glGetError in -lGL... yes
 >      checking for gluNewQuadric in -lGLU... yes
 >      checking for XmuLookupStandardColormap in -lXmu... yes
 >      checking for XListInputDevices in -lXi... yes
 >      checking for glutSwapBuffers in -lglut... no
 >      configure: error: Cannot find required glut library
 >      *** Error code 1
 > 
 >      Stop.
 >      make: stopped in /usr/pkgsrc/graphics/gle
 >      *** Error code 1
 > 
 >      Stop.
 >      make: stopped in /usr/pkgsrc/graphics/gle
 > >How-To-Repeat:
 >      update pkgsrc, cd pkgsrc/graphics/glu; make
 > >Fix:
 >      This version of gle is from 2003 -- perhaps it just needs an update...
 
 I think it's something to do with the new version of Mesa...   The 
 above error is from this:
 
  /usr/pkgsrc/graphics/gle/work.quad/.buildlink/lib/libglut.so: undefined 
reference to `glXGetProcAddressARB'
 
 which is in the library as:
 
 quad# nm /usr/pkg/lib/libGL.so | grep glXGetPro
 0017f984 t glXGetProcAddress
 0017f944 t glXGetProcAddressARB
 
 but the little 't' says it's a local function!?!?!?
 
 I don't what's going on or causing this - the symbol is defined 
 correctly in the .o file where that function lives, and I can't see 
 how or why it's now hidden...
 
 (I've gotten this error building on a 4.99.61 -current i386 box in a 
 chrooted environment.)
 
 Later...
 
 Greg Oster