Compilation problem on OSX Leopard

[GoogleCodeExporter]

Trying to compile source using Mac OS X 10.5.8

Get the following output during configure:
checking for main in -lSDL... no
configure: error: SDL is required. Please see README

I installed libsdl using darwinports, and see the following:
$ sdl-config --libs
-L/opt/local/lib -lSDLmain -lSDL -Wl,-framework,Cocoa
$ sdl-config --cflags
-I/opt/local/include/SDL -D_GNU_SOURCE=1 -D_THREAD_SAFE

But the problem persists.

Original issue reported on code.google.com by andrewsh...@gmail.com on 16 Sep 2009 at 6:37

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Original comment by acaudw...@gmail.com on 17 Sep 2009 at 1:32

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Maybe someone with OSX could tweak the configure.ac file to get this to work and
submit a patch?

Original comment by acaudw...@gmail.com on 17 Sep 2009 at 6:13

[GoogleCodeExporter]

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 craig.a....@gmail.com on 19 Sep 2009 at 6:49

Attachments:

• gource_main.patch

[GoogleCodeExporter]

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 seb.h...@gmail.com on 22 Sep 2009 at 11:53

[GoogleCodeExporter]

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 acaudw...@gmail.com on 24 Sep 2009 at 11:49

[GoogleCodeExporter]

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 acaudw...@gmail.com on 30 Sep 2009 at 6:46

[GoogleCodeExporter]

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 seb.h...@gmail.com on 30 Sep 2009 at 10:34

[GoogleCodeExporter]

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 craig.a....@gmail.com on 30 Sep 2009 at 12:48

[GoogleCodeExporter]

It appears the ftgl problem is actually an issue with Macports. Will report 
back when I 
know more.

Original comment by seb.h...@gmail.com on 30 Sep 2009 at 3:56

[GoogleCodeExporter]

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 acaudw...@gmail.com on 30 Sep 2009 at 10:00

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

My last commit should fix that crash.

Original comment by acaudw...@gmail.com on 30 Sep 2009 at 10:22

[GoogleCodeExporter]

Also now using pkg-config to get the correct FTGL cflags and libs.

Might be worth another look.

Original comment by acaudw...@gmail.com on 1 Oct 2009 at 4:29

[GoogleCodeExporter]

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 craig.a....@gmail.com on 1 Oct 2009 at 1:58

[GoogleCodeExporter]

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 acaudw...@gmail.com on 1 Oct 2009 at 8:46

[GoogleCodeExporter]

Checking for those now.

Original comment by acaudw...@gmail.com on 1 Oct 2009 at 9:20

[GoogleCodeExporter]

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 craig.a....@gmail.com on 1 Oct 2009 at 10:00

[GoogleCodeExporter]

Haha! Awesome.

Original comment by acaudw...@gmail.com on 1 Oct 2009 at 10:07

[GoogleCodeExporter]

Works for me now. Thanks

Original comment by seb.h...@gmail.com on 4 Oct 2009 at 4:13

[GoogleCodeExporter]

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 acaudw...@gmail.com on 4 Oct 2009 at 9:45

[GoogleCodeExporter]

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 seb.h...@gmail.com on 11 Oct 2009 at 6:04

[GoogleCodeExporter]

New version contains these fixes so this should work I hope :)

Original comment by acaudw...@gmail.com on 21 Oct 2009 at 4:26

• Changed state: Fixed

[GoogleCodeExporter]

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 acaudw...@gmail.com on 25 Oct 2009 at 11:08

• Changed state: Started

[GoogleCodeExporter]

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 delive...@gmail.com on 3 Nov 2009 at 2:58

[GoogleCodeExporter]

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 acaudw...@gmail.com on 3 Nov 2009 at 8:48

[GoogleCodeExporter]

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 delive...@gmail.com on 7 Nov 2009 at 1:17

[GoogleCodeExporter]

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 acaudw...@gmail.com on 7 Nov 2009 at 6:51

[GoogleCodeExporter]

This appears to be fixed in 0.16beta4

Original comment by patn...@gmail.com on 12 Nov 2009 at 4:26

[GoogleCodeExporter]

I concur with patnotz -- this now builds on Leopard with a clean repo and no 
extra
configuration.  Yay!

Original comment by delive...@gmail.com on 12 Nov 2009 at 9:28

[GoogleCodeExporter]

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 acaudw...@gmail.com on 12 Nov 2009 at 9:41

[GoogleCodeExporter]

I tried Fink, and as reported, no warnings.

Original comment by acaudw...@gmail.com on 14 Nov 2009 at 2:41

• Changed state: Fixed

[GoogleCodeExporter]

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 Aup...@gmail.com on 16 Nov 2009 at 4:26

[GoogleCodeExporter]

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 acaudw...@gmail.com on 16 Nov 2009 at 7:04

[GoogleCodeExporter]

@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 Aup...@gmail.com on 16 Nov 2009 at 8:36

[GoogleCodeExporter]

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 Aup...@gmail.com on 16 Nov 2009 at 8:41

[GoogleCodeExporter]

Cool. So your version of SDL was too new instead of too old :)

Original comment by acaudw...@gmail.com on 16 Nov 2009 at 11:06