Comments (37)
[deleted comment]
from gource.
Original comment by [email protected]
on 17 Sep 2009 at 1:32
- Added labels: Type-Enhancement
- Removed labels: Type-Defect
from gource.
Maybe someone with OSX could tweak the configure.ac file to get this to work and
submit a patch?
Original comment by [email protected]
on 17 Sep 2009 at 6:13
from gource.
I took a brief look and got it a bit further (but not working). Here's what I
did:
Built each of FreeType2, ftgl, pcre, SDL, and SDL_image from source with
./configure, make, sudo make
install. That got all the libraries in usr/local/lib where Gource's configure
finds them ok with no
modifications.
Then I patched main.cpp (see attached) to hide the Windows console calls that
don't exist on Mac OS X.
I don't have the time or the know-how to fiddle with autoconf, so I manually
edited the src/Makefile to
replace the LIBS entry
-lSDL
with
-lSDLmain -lSDL -framework Cocoa
per the FAQ entry here:
http://www.libsdl.org/faq.php?action=listentries&category=7#55
That got everything to build without error. However, there is a segmentation
fault almost immediately upon
start-up with no other messages, so there is still something fundamental
missing. I'm out of time to look at it
further, but maybe this helps someone else who's interested.
Original comment by [email protected]
on 19 Sep 2009 at 6:49
Attachments:
from gource.
It seems that they might have instructions at http://www.libsdl.org/faq.php?
action=listentries&category=3#21 , but I'm afraid I don't have any autoconf
experience
so I'm not sure if that is helpful?
Original comment by [email protected]
on 22 Sep 2009 at 11:53
from gource.
I was just thinking "There's probably an sdl.m4 somewhere" and there it is...
in the
FAQ :) I might change it to use this on the weekend.
Original comment by [email protected]
on 24 Sep 2009 at 11:49
from gource.
I've just changed configure.ac to use sdl.m4 as per the FAQ.
Would someone like to maybe check out the code from github
(http://github.com/acaudwell/Gource) and see if we're further along?
Thanks.
Original comment by [email protected]
on 30 Sep 2009 at 6:46
from gource.
Yes, this gets it a little further. The next problem is that ftgl isn't found,
I wonder what
is missing there now
Original comment by [email protected]
on 30 Sep 2009 at 10:34
from gource.
It now builds successfully (if you have previously built and installed the
prerequisites, like ftgl). But it still
crashes on start-up as follows:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0xfffffffc
0x920407d4 in __gnu_cxx::__exchange_and_add ()
(gdb) backtrace
#0 0x920407d4 in __gnu_cxx::__exchange_and_add ()
#1 0x9202de54 in std::string::_Rep::_M_dispose ()
#2 0x9203008c in std::string::assign ()
#3 0x00004b2c in std::string::_M_rep () at basic_string.h:140
#4 0x00004b2c in ~basic_string [inlined] () at display.cpp:472
#5 0x00004b2c in ~basic_string [inlined] () at basic_string.h:472
#6 0x00004b2c in SDLAppDisplay::detectPath (this=<value temporarily
unavailable, due to optimizations>)
at display.cpp:140
#7 0x00004db4 in SDLAppDisplay::SDLAppDisplay (this=0x3cf24) at display.cpp:40
#8 0x00035c5c in __static_initialization_and_destruction_0
(__initialize_p=<value temporarily unavailable,
due to optimizations>, __priority=<value temporarily unavailable, due to
optimizations>) at display.cpp:32
#9 0x8fe13834 in
__dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkContextE
()
#10 0x8fe0f248 in
__dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEj ()
#11 0x8fe0f36c in __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextE
()
#12 0x8fe03848 in __dyld__ZN4dyld24initializeMainExecutableEv ()
#13 0x8fe08144 in __dyld__ZN4dyld5_mainEPK11mach_headermiPPKcS5_S5_ ()
#14 0x8fe01774 in __dyld__ZN13dyldbootstrap5startEPK11mach_headeriPPKcl ()
#15 0x8fe01048 in __dyld__dyld_start ()
Original comment by [email protected]
on 30 Sep 2009 at 12:48
from gource.
It appears the ftgl problem is actually an issue with Macports. Will report
back when I
know more.
Original comment by [email protected]
on 30 Sep 2009 at 3:56
from gource.
Craig:
Thanks. That should be easy to fix. it's because one global object (display) is
calling another global object (texturemanager) in its constructor before the
other
has been constructed... it just happens that on the other platforms they getting
constructed in a different order.
I will change how that works.
Original comment by [email protected]
on 30 Sep 2009 at 10:00
from gource.
[deleted comment]
from gource.
My last commit should fix that crash.
Original comment by [email protected]
on 30 Sep 2009 at 10:22
from gource.
Also now using pkg-config to get the correct FTGL cflags and libs.
Might be worth another look.
Original comment by [email protected]
on 1 Oct 2009 at 4:29
from gource.
The crash is fixed, thanks. For me (building everything from source) the
pkg-config made no discernible
difference in the build process except I had to build and install pkg-config to
get configure to run. Maybe it
will help the MacPorts folks.
What I now see is that it bails out as soon as it starts to draw a window with:
failed to load image /usr/local/share/gource/beam.png
The file exists and I have read access to it:
% ls -l /usr/local/share/gource/beam.png
-rwxr-xr-x@ 1 root wheel 358 Sep 30 19:24 /usr/local/share/gource/beam.png
Not sure offhand how to debug that further.
Original comment by [email protected]
on 1 Oct 2009 at 1:58
from gource.
I think we're almost there.
You probably need libpng (and libjpeg if you want to load jpegs though none are
included):
"As of SDL_image 1.2.5, JPEG, PNG, and TIFF image loading libraries are
dynamically
loaded, so if you don't need to load those formats, you don't need to include
those
shared libraries. libpng depends on libz, and libtiff depends on both libz and
libjpeg."
I will make autoconf check for those.
Original comment by [email protected]
on 1 Oct 2009 at 8:46
from gource.
Checking for those now.
Original comment by [email protected]
on 1 Oct 2009 at 9:20
from gource.
Excellent. Built libpng and libjpeg, rebuilt SDL_image, then gource, and now
gource is happy. I'm currently
watching Larry Wall create Perl 20 years ago, all the more impressive since the
data were converted from
something to Perforce and then Perforce to git.
Original comment by [email protected]
on 1 Oct 2009 at 10:00
from gource.
Haha! Awesome.
Original comment by [email protected]
on 1 Oct 2009 at 10:07
from gource.
Works for me now. Thanks
Original comment by [email protected]
on 4 Oct 2009 at 4:13
from gource.
Cool. Seb: does that mean you got it to work with FTGL 2.1.2 or did you need
2.1.3?
Btw, I edited the SDL and FTGL #include paths the other day as I was having
trouble
building on windows, I wonder if they are still found on Mac?
Original comment by [email protected]
on 4 Oct 2009 at 9:45
from gource.
Needed 2.1.3, there's no working 0.2.1.2 for OS X, it appears. Shouldn't be a
problem,
though, as I'm slowly convincing the macports devs to ship 2.1.3 as a
ftgl-devel
package or something.
Original comment by [email protected]
on 11 Oct 2009 at 6:04
from gource.
New version contains these fixes so this should work I hope :)
Original comment by [email protected]
on 21 Oct 2009 at 4:26
- Changed state: Fixed
from gource.
There is still some problem it seems:
http://trac.macports.org/ticket/22192
There a few possibilities I would guess:
* the order I'm linking things is wrong
* AX_CHECK_GLU is producing the wrong libs on some Macs
* some of the libaries themselves (SDL, SDL_image, FTGL) link against different
versions of GL - hard for me to do anything about that.
It appears Gource builds without AX_CHECK_GLU (at least for me) since FTGL
seems to
have all the Opengl symbols (somehow, not linking expert), though it seems like
a
hack just to take that out, and I'm not sure that's the problem.
Anyone have any bright ideas?
Original comment by [email protected]
on 25 Oct 2009 at 11:08
- Changed state: Started
from gource.
I was, after hours of having the same problem, finally able to figure it out.
When you run ./configure without any arguments, there's a linking problem that
eventually creeps in. Some of the libraries will link against Mesa (the X11
OpenGL
implementation), and some of the libraries will link against the OpenGL
framework
that comes with Quartz (I think?). This makes it go boom when it tries to load
in a
texture.
If you run "./configure --without-x", the Mesa libraries don't get linked in and
everything works fine. Is there a way to have this the default on Leopard?
I also had issues with the version of SDL that came via Fink, and the version
that
came via "Ports". Both seem to work, but one (I think Fink) has the SDL
libraries in
/sw/include while the other has them in /sw/include/SDL and Gource prefers the
latter. If you run into a case where ./configure works but then make complains
about
missing SDL headers, open the src/Makefile and src/core/Makefile and change the
CPPFLAGS line at the top of each from -I/sw/include/SDL to -I/sw/include and you
should be good to go.
I still had to clone and manually compile FTGL, as neither Fink nor MacPorts has
2.1.3~rc5 as of this writing.
But! But! Once I did all of that, it works like a charm. (And I learned more
than
I ever wanted to know about gdb and otool and dynamic linking in the process.)
Original comment by [email protected]
on 3 Nov 2009 at 2:58
from gource.
Interesting. Thanks for the report.
I've been trying to get it to work on Leopard on a borrowed testing Mac at work.
The main problem I am seeing is this warning when you run Gource about SDL and
SDL_Image implementing the same functions (I'm using macports):
objc[58644]: Class SDLTranslatorResponder is implemented in both
/opt/local/lib/libSDL-1.2.0.dylib and /opt/local/lib/libSDL_image-1.2.0.dylib.
Using
implementation from /opt/local/lib/libSDL_image-1.2.0.dylib.
objc[58644]: Class SDL_QuartzView is implemented in both
/opt/local/lib/libSDL-1.2.0.dylib and /opt/local/lib/libSDL_image-1.2.0.dylib.
Using
implementation from /opt/local/lib/libSDL_image-1.2.0.dylib.
objc[58644]: Class SDL_QuartzWindowDelegate is implemented in both
/opt/local/lib/libSDL-1.2.0.dylib and /opt/local/lib/libSDL_image-1.2.0.dylib.
Using
implementation from /opt/local/lib/libSDL_image-1.2.0.dylib.
objc[58644]: Class SDL_QuartzWindow is implemented in both
/opt/local/lib/libSDL-1.2.0.dylib and /opt/local/lib/libSDL_image-1.2.0.dylib.
Using
implementation from /opt/local/lib/libSDL_image-1.2.0.dylib.
I managed to get Gource to work by moving -lSDL_image after -lSDL in the LIBS
(which
it probably should've been anyway I guess) though that warning still appears
whenever
it runs.
I just tried --without-x and I still get the same warnings so it didn't seem to
be
the issue (for me), though people making a port/package for Macs may want to
include
that setting. I'm not quite sure how to make this the default.
If you have any idea how to stop the warnings that'd be a great help.
Btw FTGL 2.1.3 rc5 is now in Macports (Thanks to Seb for getting them to update
it).
Original comment by [email protected]
on 3 Nov 2009 at 8:48
from gource.
I fiddled with this some more on my Leopard MBP. I upgraded to Gource 0.16b2
(bceee7..57b15a), cleaned out my manually-compiled FTGL, and installed
2.1.3~rc5 from
MacPorts.
From there, I've tried two different setups.
Setup 1: MacPorts libsdl 1.2.14, libsdl_image 1.2.8
Pro: Works without twiddling Makefiles
Con: Warnings about dual implementation of SDL methods
Setup 2: Fink libsdl 1.2.14-5, libsdl_image 1.2.8-2
Pro: No warning about dual implementation
Con: Have to twiddle Makefiles to change /sw/include/SDL to /sw/include
Neither is perfect, and both still require you to ./configure --without-x, but
both work.
Original comment by [email protected]
on 7 Nov 2009 at 1:17
from gource.
I think I have fixed the SDL header issue.
If I can find an example of the correct way to turn off the X package in
configure on
Macs I will do that too.
Original comment by [email protected]
on 7 Nov 2009 at 6:51
from gource.
This appears to be fixed in 0.16beta4
Original comment by [email protected]
on 12 Nov 2009 at 4:26
from gource.
I concur with patnotz -- this now builds on Leopard with a clean repo and no
extra
configuration. Yay!
Original comment by [email protected]
on 12 Nov 2009 at 9:28
from gource.
Yep I've defaulted configure to build without x on Macs (--with-x will give you
the
old behavior).
The SDL_image warnings are still there...
Original comment by [email protected]
on 12 Nov 2009 at 9:41
from gource.
I tried Fink, and as reported, no warnings.
Original comment by [email protected]
on 14 Nov 2009 at 2:41
- Changed state: Fixed
from gource.
Using MacPorts, still getting issues at make:
g++ -g -O2 -D_THREAD_SAFE -I/opt/local/include/SDL -D_GNU_SOURCE=1 -
D_THREAD_SAFE -I/opt/local/include/freetype2 -I/opt/local/include -
I/opt/local/include -I/opt/local/include/FTGL -I/opt/local/include/freetype2 -
DSDLAPP_RESOURCE_DIR=\"/opt/local/share/gource/\" -c -o display.o display.cpp
display.cpp: In member function ‘void SDLAppDisplay::init(std::string, int,
int, bool)’:
display.cpp:175: error: ‘SDL_GL_SWAP_CONTROL’ was not declared in this scope
display.cpp:176: error: ‘SDL_GL_SWAP_CONTROL’ was not declared in this scope
make[2]: *** [display.o] Error 1
make[1]: *** [all] Error 2
make: *** [all] Error 2
Original comment by [email protected]
on 16 Nov 2009 at 4:26
from gource.
Hi.
Sounds like you have an old build of SDL before SDL 1.2.10 when
SDL_GL_SWAP_CONTROL
apparently was added. I'm pretty sure if you update your SDL libraries it will
work.
I will bump the minimum version to 1.2.10.
Original comment by [email protected]
on 16 Nov 2009 at 7:04
from gource.
@acaudwell
I have:
$ port list installed | grep sdl
libsdl-devel @1.3.0-5179 devel/libsdl-devel
libsdl_image @1.2.8 devel/libsdl_image
They are the latest packages on MacPorts (there's also libsdl @1.2.14).
Original comment by [email protected]
on 16 Nov 2009 at 8:36
from gource.
Update: Uninstalled libsdl-devel from MacPorts, installed regular libsdl
instead. Had to
reinstall libsdl_image after the change, but now it works perfectly!
Original comment by [email protected]
on 16 Nov 2009 at 8:41
from gource.
Cool. So your version of SDL was too new instead of too old :)
Original comment by [email protected]
on 16 Nov 2009 at 11:06
from gource.
Related Issues (20)
- Gource fails on OS X 10.9 HOT 3
- Unable to find git.exe? HOT 3
- Creating a custom version of gource HOT 4
- Allow localized display of date/time HOT 1
- ffmpeg gets IO errors about 3/4 way through gource PPM file HOT 8
- Question about Gource Output HOT 1
- Gource will not accept my .log HOT 8
- Version of freetype2 less than 9.0.3 error HOT 2
- Gource displays underscore as +af8- HOT 1
- It's not an issue HOT 1
- Move old captions up, display new ones at bottom HOT 1
- Git Rebase
- configure fails on systems w/o explicit /usr/lib64 (i.e. ubuntu & possibly others w/ /usr/lib/x86_64-linux-gnu/)
- what is this command line you speak of HOT 2
- Can't find git.exe. HOT 2
- Size does metter - feature request ... HOT 1
- --highlight-colour not working HOT 1
- --dir-name-depth not working reliably HOT 3
- --dir-name-depth not working reliably HOT 2
- display directory names at directory nodes, not along edges
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gource.