On Mon, Oct 04, 2004 at 10:37:53AM +0200, Thomas Klausner wrote:
> On Mon, Oct 04, 2004 at 06:04:19PM +1000, grant beattie wrote:
> > On Mon, Oct 04, 2004 at 09:14:19AM +0300, Martti Kuparinen wrote:
> > 
> > > configure:9279: checking for gluNewQuadric in -lGLU
> > > configure:9310: gcc -o conftest -O2 -I/usr/pkg/include -DGLX_GLXEXT_LEGACY 
> > > -Wall -I/usr/pkg/include -DGLX_GLXEXT_LEGACY -L/usr/pkg/lib 
> > > -Wl,-R/usr/pkg/lib -L/usr/X11R6/lib -Wl,-R/usr/X11R6/lib conftest.c -lGLU  
> > > -lSM -lICE -lGL  -L/usr/X11R6/lib -lX11   -lm >&5
> > > /usr/pkgsrc/graphics/gle/work/.buildlink/lib/libGLU.so: undefined reference 
> > > to `operator new[](unsigned)'
> > > /usr/pkgsrc/graphics/gle/work/.buildlink/lib/libGLU.so: undefined reference 
> > > to `vtable for __cxxabiv1::__si_class_type_info'
> > > /usr/pkgsrc/graphics/gle/work/.buildlink/lib/libGLU.so: undefined reference 
> > > to `operator delete(void*)'
> > > /usr/pkgsrc/graphics/gle/work/.buildlink/lib/libGLU.so: undefined reference 
> > > to `__gxx_personality_v0'
> > > /usr/pkgsrc/graphics/gle/work/.buildlink/lib/libGLU.so: undefined reference 
> > > to `__cxa_pure_virtual'
> > > /usr/pkgsrc/graphics/gle/work/.buildlink/lib/libGLU.so: undefined reference 
> > > to `vtable for __cxxabiv1::__class_type_info'
> > > /usr/pkgsrc/graphics/gle/work/.buildlink/lib/libGLU.so: undefined reference 
> > > to `operator delete[](void*)'
> > > /usr/pkgsrc/graphics/gle/work/.buildlink/lib/libGLU.so: undefined reference 
> > > to `vtable for __cxxabiv1::__vmi_class_type_info'
> > > /usr/pkgsrc/graphics/gle/work/.buildlink/lib/libGLU.so: undefined reference 
> > > to `operator new(unsigned)'
> > > collect2: ld returned 1 exit status
> > 
> > it needs to use g++ to link, not gcc.
> 
> Add adding
> USE_LANGUAGES=	c c++
> makes it pass the configure part for me.
> 
> I'm a bit confused why exactly this works, and if we should add
> this to the package or not, since it only consists of C (not C++)
> files.

I've seen this problem in gtkspell, too, and the USE_LANGUAGES addition
of c++ doesn't help in that one.

As to why we're seeing this now - I suspect that changes either to the
libtool stuff (which I doubt), or the buildlink -> wrapper conversion
has unearthed a bug that was hidden before. i.e. that if a library is
built with g++, then the configure scripts which determine whether
that library exists by trying to link it in must also use g++ to
discover this.

Regards,
Alistair