Does not build on OSX 10.7

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Download source
2. Run make

What is the expected output? What do you see instead?
* Compiled binary
* Lots of errors.  It looks like the app was built using allegro 4, but 
Macports only supports allegro 5 on OSX 10.7 or later.

What version of the product are you using? On what operating system?
* svn trunk, OSX 10.7.5

Please provide any additional information below.
* I'm working through the compiler issues, but it's slow going, since I can 
only work on this during lunch break and after hours.

Original issue reported on code.google.com by ear...@gmail.com on 21 Feb 2013 at 7:45

[GoogleCodeExporter]

A substantial amount of EOF would have to be rewritten in order to build with 
Allegro 5, and that was going to be put off until EOF 2.0.  I'm less versed on 
Mac development, but I remember hearing something along the lines of newer 
versions of OSX had changes that broke functionality of Allegro 4, so I'm 
guessing you don't have the option of manually building Allegro 4?

We could ask Todd to make you an OSX package, as he makes the binary for each 
beta version and release candidate.  Luckily though, the last release candidate 
was only two revisions ago, so you can get that binary in this thread:
http://www.fretsonfire.net/forums/viewtopic.php?f=11&t=50698

Original comment by raynebc on 22 Feb 2013 at 8:22

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Yeah, I came to the same conclusion regarding allegro 4 vs 5 last night - 
sorry, I should've updated the bug, but I was collapsing at that point.

FWIW, it looks like adding these 4 declarations to allegro 4's header aintosx.h 
are enough to get allegro 4 to build, although I didn't have time to check if 
this would still allow production of operable binaries. AFAIK, OSX 10.7's SDK 
removed the declarations for these (and probably others that aren't used by 
allegro 4).  I'm not sure if the library files still include connections to the 
implementations, or not.

int QDDone(GrafPtr);
CFDictionaryRef CGDisplayCurrentMode ( CGDirectDisplayID display);
enum { useDistantHdwrMem = 1L << 4 };
enum { useLocalHdwrMem = 1L << 5 };

It's conceivable that one could build allegro4 against the 10.6 SDK, but I'm 
not versed enough in cmake to know how to ask it politely (or rudely) to do 
that.

Original comment by ear...@gmail.com on 22 Feb 2013 at 12:41

[GoogleCodeExporter]

If you have the 10.6 SDK, Allegro 4 can easily be built with it. In the cmake 
GUI there is a section where you can set the SDK version. The command line 
option is:

 -DCMAKE_OSX_SYSROOT=/Developer/SDKs/MacOSX10.6.sdk

You will probably also be interested in CMAKE_OSX_DEPLOYMENT_TARGET. I use the 
10.5 SDK and set the deployment target to 10.5 when I build it.

If you plan on distributing the build to others, you might also want to set 
CMAKE_OSX_ARCHITECTURES to ppc;i386 as this will allow it to run on the 
greatest number of configurations.

Original comment by xander4j...@yahoo.com on 6 Apr 2013 at 4:14

[GoogleCodeExporter]

I managed to build and run it with these rough notes:
curl -O http://downloads.xiph.org/releases/ogg/libogg-1.3.0.tar.gz
curl -O http://downloads.xiph.org/releases/vorbis/libvorbis-1.3.3.tar.gz
curl -o allegro-4.4.2.tar.gz -L 
http://sourceforge.net/projects/alleg/files/allegro/4.4.2/allegro-4.4.2.tar.gz/d
ownload
curl -o oggvideotools-0.8a.tar.gz -L 
http://sourceforge.net/projects/oggvideotools/files/oggvideotools/oggvideotools-
0.8a/oggvideotools-0.8a.tar.gz/download
curl -O http://www.fftw.org/fftw-3.3.3.tar.gz
tar xfz libogg-1.3.0.tar.gz
tar xfz libvorbis-1.3.3.tar.gz
tar xfz allegro-4.4.2.tar.gz
tar xfz fftw-3.3.3.tar.gz
cd libogg-1.3.0
./configure --disable-dependency-tracking
make CFLAGS="-arch x86_64 -arch i386" LDFLAGS="-arch x86_64 -arch i386"
sudo make install
cd ../libvorbis-1.3.3
./configure --disable-dependency-tracking
make CFLAGS="-arch x86_64 -arch i386" LDFLAGS="-arch x86_64 -arch i386"
sudo make install
cd ../allegro-4.4.2
mkdir build
cd build
cmake -DCMAKE_OSX_SYSROOT=/Developer/SDKs/MacOSX10.6.sdk 
-DCMAKE_OSX_DEPLOYMENT_TARGET=10.6 ..
make -j8
sudo make install
cd ../../fftw-3.3.3
./configure --disable-dependency-tracking
make CFLAGS="-arch x86_64 -arch i386" LDFLAGS="-arch x86_64 -arch i386"
sudo make install

But when I try to run the app, It complains about being unable to load some 
oggs from eof.dat, and drawing the waveform for guitar.ogg makes the upper half 
fully black and the lower half fully green. Playing it back just results in a 
buzz in the speakers. The claps and metronome sounds just fine though. Any idea 
what might be amiss? 

$ ./EOF.app/Contents/MacOS/eof
2013-04-29 12:35:44.579 eof[59142:5d0b] Warning once: This application, or a 
library it uses, is using NSQuickDrawView, which has been deprecated. Apps 
should cease use of QuickDraw and move to Quartz.
Apr 29 12:35:44 Thunder.local eof[59142] <Error>: The function `CGSFlushWindow' 
is obsolete and will be removed in an upcoming update. Unfortunately, this 
application, or a library it uses, is using this obsolete function, and is 
thereby contributing to an overall degradation of system performance. Please 
use `CGSFlushWindowContentRegion' instead.
LAME 3.99.5 64bits (http://lame.sf.net)
Using polyphase lowpass filter, transition band: 16538 Hz - 17071 Hz
Encoding check.wav to check.mp3
Encoding as 44.1 kHz single-ch MPEG-1 Layer III (11x)  64 kbps qval=3
Öppnar med wav-modul: WAV file reader
Encoding "silence.wav" to
         "silence.ogg"
at approximate bitrate 128 kbps (VBR encoding enabled)

Kodning av "silence.ogg" klar

    Fillängd:  0m 00,0s
    Förlupen tid: 0m 00,0s
    Förhålland:         0,0698
    Genomsnittlig bithastighet: 248,6 kb/s

sh: oggCat: command not found
Couldn't load sample eof.dat#piano.esp/NOTE_37_OGG!2013-04-29 12:35:44.725 
eof[59142:5d0b] NSAlert is being used from a background thread, which is not 
safe.  This is probably going to crash sometimes. Break on void 
_NSAlertWarnUnsafeBackgroundThreadUsage() to debug.  This will be logged only 
once.  This may break in the future.
Couldn't load sample eof.dat#piano.esp/NOTE_39_OGG!Couldn't load sample 
eof.dat#piano.esp/NOTE_41_OGG!Couldn't load sample 
eof.dat#piano.esp/NOTE_43_OGG!Couldn't load sample 
eof.dat#piano.esp/NOTE_45_OGG!Couldn't load sample 
eof.dat#piano.esp/NOTE_47_OGG!Couldn't load sample 
eof.dat#piano.esp/NOTE_49_OGG!Couldn't load sample 
eof.dat#piano.esp/NOTE_51_OGG!Couldn't load sample 
eof.dat#piano.esp/NOTE_53_OGG!Couldn't load sample 
eof.dat#piano.esp/NOTE_55_OGG!Couldn't load sample 
eof.dat#piano.esp/NOTE_57_OGG!Couldn't load sample 
eof.dat#piano.esp/NOTE_59_OGG!Couldn't load sample 
eof.dat#piano.esp/NOTE_61_OGG!Couldn't load sample 
eof.dat#piano.esp/NOTE_63_OGG!Couldn't load sample 
eof.dat#piano.esp/NOTE_65_OGG!Couldn't load sample 
eof.dat#piano.esp/NOTE_67_OGG!Couldn't load sample 
eof.dat#piano.esp/NOTE_69_OGG!Couldn't load sample 
eof.dat#piano.esp/NOTE_71_OGG!Couldn't load sample 
eof.dat#piano.esp/NOTE_73_OGG!Couldn't load sample 
eof.dat#piano.esp/NOTE_75_OGG!Couldn't load sample 
eof.dat#piano.esp/NOTE_77_OGG!Couldn't load sample 
eof.dat#piano.esp/NOTE_79_OGG!Couldn't load sample 
eof.dat#piano.esp/NOTE_81_OGG!Couldn't load sample 
eof.dat#piano.esp/NOTE_83_OGG!Couldn't load sample 
percussion.dat#cowbell.ogg!Couldn't load sample 
percussion.dat#tambourine2.ogg!Couldn't load sample 
percussion.dat#triangle1.ogg!Couldn't load sample 
percussion.dat#woodblock1.ogg!Couldn't load sample 
percussion.dat#woodblock3.ogg!Couldn't load sample 
percussion.dat#woodblock5.ogg!Couldn't load sample 
percussion.dat#woodblock7.ogg!Couldn't load sample 
percussion.dat#woodblock9.ogg!Couldn't load sample 
percussion.dat#clap1.ogg!Couldn't load sample percussion.dat#clap3.ogg!

Original comment by quarns...@gmail.com on 29 Apr 2013 at 10:41

[GoogleCodeExporter]

I case it's of any help, ov_open_callbacks called from 
alogg_create_ogg_from_buffer returns OV_EBADHEADER "Invalid Vorbis bitstream 
header" for the ogg samples that fail. No errors for the "guitar.ogg".

Original comment by quarns...@gmail.com on 29 Apr 2013 at 11:36

[GoogleCodeExporter]

Update: the issue with the oggs was this: 
https://trac.xiph.org/ticket/1805#comment:1, so now I've got a fully working 
(afaict) build up and running :)

Original comment by quarns...@gmail.com on 29 Apr 2013 at 4:00

[GoogleCodeExporter]

Wow- was able to use the -DCMAKE_OSX_SYSROOT option as above & build allegro4 
properly, so now I can actually build a working EOF! Sweet!

Original comment by ea.th1rtyf0ur on 12 Mar 2014 at 2:13

[GoogleCodeExporter]

This issue resolved then?

Original comment by raynebc on 25 Apr 2014 at 10:20

[GoogleCodeExporter]

For now I'm going to assume so.  Please reply if not.

Original comment by raynebc on 29 May 2014 at 11:00

• Changed state: Done