Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
GoogleCodeExporter opened this issue Feb 20, 2016 · 10 comments

Comments

@GoogleCodeExporter
Copy link

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
Copy link
Author

Here is the dump:

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

Attachments:

@GoogleCodeExporter
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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

  • Changed state: Done

@GoogleCodeExporter
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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

  • Changed state: Accepted

@GoogleCodeExporter
Copy link
Author

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

  • Changed state: Fixed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant