tboudreaux / gource

Automatically exported from code.google.com/p/gource
0 stars 0 forks source link

gource fails with segmentation fault when installed with MacPorts on OSX #51

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Install gource with MacPorts
2. start gource

What is the expected output? What do you see instead?
Gource should start and try do its thing.  Gource crashes with a segmentation 
fault instead.

What version of the product are you using? On what operating system?
0.23 which is the newest from MacPorts.

Please provide any additional information below.
I have +universal set as default

Original issue reported on code.google.com by don...@gmail.com on 8 Mar 2010 at 8:30

GoogleCodeExporter commented 8 years ago
Here is the dump:

Original comment by don...@gmail.com on 8 Mar 2010 at 8:39

Attachments:

GoogleCodeExporter commented 8 years ago
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.

Original comment by acaudw...@gmail.com on 8 Mar 2010 at 10:11

GoogleCodeExporter commented 8 years ago
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?

Original comment by don...@gmail.com on 8 Mar 2010 at 10:34

GoogleCodeExporter commented 8 years ago
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?

Original comment by don...@gmail.com on 8 Mar 2010 at 10:49

GoogleCodeExporter commented 8 years ago
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

Original comment by acaudw...@gmail.com on 9 Mar 2010 at 4:31

GoogleCodeExporter commented 8 years ago

Original comment by acaudw...@gmail.com on 9 Mar 2010 at 4:32

GoogleCodeExporter commented 8 years ago
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

Original comment by raimue on 27 Mar 2010 at 3:04

GoogleCodeExporter commented 8 years ago
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.

Original comment by acaudw...@gmail.com on 27 Mar 2010 at 4:25

GoogleCodeExporter commented 8 years ago

Original comment by acaudw...@gmail.com on 4 Apr 2010 at 5:43

GoogleCodeExporter commented 8 years ago
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

Original comment by acaudw...@gmail.com on 4 Apr 2010 at 6:47