gource fails with segmentation fault when installed with MacPorts on OSX about gource HOT 10 CLOSED

Here is the dump:

Hi.

If possible it would be good if you could isolate the function call that is 
causing
the crash by building Gource from the tarball - should be easy as you already 
have
the dependencies installed - and adding printfs between the calls in
src/core/texture.cpp:TextureResource::TextureResource() function where the 
crash is
happening, and maybe find out what arguments we're passing it.

This will be my first time debugging a macPorts install, and I need all the 
help I can get.  :)

I'll start by locating the source :)  Then, I hope, I only have to edit the 
source and try installing again, using 
MacPorts?

I have now downloaded the tarball and configured and completed "make".

Running ./gource works!

That indicates that my dependencies are OK, but the 0.23 version installed from 
MacPorts is faulty, right?

I hope 0.25 can be released through MacPorts soon, but for now, I can use the 
one I built from the tarball.

BTW:  I cloned gource from GutHub, but the source did not include a configure 
script.  Why is that?

Cool I'm glad it works. Sounds like its a problem with how its built by 
Macports scripts?

There is a 0.25 version of Gource for Macports waiting to get approved here:
http://trac.macports.org/ticket/23891

configure and the other missing files get added by running autoreconf -f -i

Cheers

Andrew

This seems to be a problem which only occurs when `mesa` from MacPorts is being
installed and active. When this is the case, gource links against
`/opt/local/lib/libGLU.1.dylib` and `/opt/local/lib/libGL.1.dylib` instead of 
the
system provided `OpenGL.framework`.

See also the MacPorts bug tracker: http://trac.macports.org/ticket/23987

I wonder if Macports calls configure with --with-x?

That might also explain why someone with this problem got Gource working simply 
by
building it themselves instead of from Macports, as my configure script sets
with_x=no by default unless --with-x was used.

I do this as m4/ax_check_gl.m4 (http://code.google.com/p/autoconf-gl-macros) 
uses
$no_x to decide which version of GL to use.

Also it appears those scripts have a new version released recently. So that 
might be
worth trying too.

I tried updating the GL autoconf macros (above), and that fixed the issue. They
appear to have changed the logic that decides which GL library to use. I will 
include
them with the next version.

For reference, I duplicated the issue by building with:

LDFLAGS='-L/opt/local/lib' ./configure --prefix=/opt/local