OS X issues

[GoogleCodeExporter]

I tried building mupen on OS X, here's a summary of build-time issues I met
and have not really fixed (the list is a little long, sorry =)

* On my computer some types like 'GL_UNSIGNED_BYTE_3_3_2_EXT' were not
picked up even if I included the glext.h header in which they are
defined... I suspect this happens because they are wrapped inside a #if,
not sure how to activate them. Will need investigation - also I'm not sure
everyone on mac will meet this. More feedback needed here. The same thing
happens with stuff like 'GL_COMBINE_EXT'

* In the glN64 makefile, I needed to add "LDFLAGS += -lpng" otherwise
libpng symbols were missing at link time

* In 'glN64/Config_gtk2.cpp', #include <features.h> fails because there is
no such header. Commenting out the said line seems to make it build fine

* In 'glN64/NV_register_combiners.h', I needed to '#define APIENTRY'
because it was apparently not done in GL headers. There once again I'd need
feedback from other OS X users (especially those with more recent versions
of the OS)

* In pre.mk : the part that checks for GTK presence does not work, it
complains that 'head' does not accept '-c' flags. There, once again, it is
likely the BSD/OSX version is different from the linux one.
* In pre.mk : 'strip' does not take '--strip-all' flags on OS X. I simply
replaced it with 'strip -S' (strip debug symbols only) as I was unsure of
the proper equivalent. It may be 'strip' alone.
* In pre.mk : PLUGIN_LDFLAGS needed to be set to 'PLUGIN_LDFLAGS    = -bundle'
instead since we don't use GNU ld.
* In pre.mk : LIBGL_LIBS needed to be changed to 'LIBGL_LIBS    = -framework
OpenGL' (the -framework switch behaves a little like pkg-config in case you
are wondering)

* jttl_audio seems totally unusable, it includes Linux headers and uses
ther contents everywhere

* GL_COMBINE4_NV was unknown on my computer. There once again I'd need
feedback from other OS X users (especially those with more recent versions
of the OS) Same thing with 'GL_MIRRORED_REPEAT_IBM'

* rice_video/RenderBase.cpp does not have a NO_ASM equivalent for
ProcessVertexDataSSE (only needed on PPC macs, not really needed since PPC
support is broken anyway, but just to let it build...)

* rice_video/Config.h : had problems with "#pragma pack()", "Config.h:361:
error: too many #pragma options align=reset". Commenting it out seems to
make it work.

* When building, the makefile used 'gcc' to link even though C++ files were
built. I needed to switch linking to g++ with a MUPENCC = $(CXX)

* In 'makefile', '-Wl,-export-dynamic' is used. This flag does not exist
directly in the OS X linker. I am unsure of the correct equivalent. Simply
removing the flag got it to build and link but it may not be correct.

* I get multiple 'warning: -fpic is not supported; -fPIC assumed'

* mupen64_audio seems unusable, it includes linux headers and uses them
heavily.
* main/volume.c seems unusable, it includes linux headers and uses them
heavily.
* blight_input seems unusable, it includes linux headers and uses them heavily.

* glide64/Makefile uses its own strip command instead of using the one from
pre.mk

* in install.sh, flag -D is used. This flag apparently does not exist in
the BSD/OSX version of install. I am yet unsure of the correct equivalent,
but just removing the flag seems to make it work anyway.

Original issue reported on code.google.com by auria...@gmail.com on 7 Jun 2008 at 1:34

[GoogleCodeExporter]

I meant "mupen64_audio" and not "jttl_audio"

Original comment by auria...@gmail.com on 13 Jun 2008 at 11:54

[GoogleCodeExporter]

Putting refactoring plugins to use GLTypes into this issue as the 105 
typecasting 
patch won't be applied. 

Original comment by sknau...@wesleyan.edu on 28 Jul 2008 at 4:12

[GoogleCodeExporter]

Just some comments:

mupen64_audio has been removed.
The volume.c "linux" dependence is now in jttl_audio and is really an OSS (Open 
Sound System) dependence. OSX doesn't use this, but say our FreeBSD port does. 
We 
now support SDL modulation as well so theoretically sound will work on OSX. 
Some 
propertly placed ifdefs to disbale OSS on non-supported platforms should work.

The linux dependence in blight is only for rumble and easily encapsulated.

As mentioned in the 105 comments, the proposed changes for LDFLAGS breaks linux 
support and can't be folded in, as-is.

Original comment by sknau...@wesleyan.edu on 29 Jul 2008 at 12:00

[GoogleCodeExporter]

#include <features.h> removed from glN64/Config_gtk2.cpp as of r819 as it was 
not 
needed.

Original comment by sknau...@wesleyan.edu on 29 Jul 2008 at 12:02

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Small addition : in glide64/rdp.cpp,

#define BYTESWAP1(s1) asm volatile (" bswap %0; " : "+r" (s1) : :);
#define BYTESWAP2(s1,s2) asm volatile (" bswap %0; bswap %1; " : "+r" (s1), 
"+r" (s2)
: :);

have no NO_ASM equivalent.

Original comment by auria...@gmail.com on 20 Aug 2008 at 12:53

[GoogleCodeExporter]

* neaten up a lot of dependency checks
  * don't check for GTK if not building for GTK
  * don't pass the GTK flags to the plugins

* when we pull in the opengl headers, change GL/gl.h and GL/glu.h to 
SDL_opengl.h
  * for i in $(grep -lr 'GL/gl.h' *) $(grep -lr 'GL/glu.h' * ) ; do sed -ie
's,GL/gl.h,SDL_opengl.h,g' $i ; sed -ie 's,GL/glu.h,SDL_opengl.h,g' $i ; done
  * <Tillin9>SDL_opengl.h is basically a big wrapper for gl.h 
                  (with some extra prototype stuff), so 100% replacing should 
                  be okay. If it isn't, its a weird gl extension issue in mupen 
                  and technically a bug.

* pre.mk
  * add 'uname -s' and set a variable in case of Darwin
  * STRIP   = strip
  * LIBGL_LIBS      = -framework OpenGL
-Wl,-dylib_file,/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries
/libGL.dylib:/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/li
bGL.dylib
  * PLUGIN_LDFLAGS  = -bundle
  * LDFLAGS = -lstdc++

* add a bunch of #ifdef __linux__ around the blight rumble stuff.

* build the supporting plugins
  * for i in glN64 mupen64_input blight_input dummy_audio rsp_hle ; do cd $i ; make ;
cd .. ; done
  * ln -s ../glN64/glN64.so plugins/
    ln -s ../mupen64_input/mupen64_input.so plugins/
    ln -s ../blight_input/blight_input.so plugins/
    ln -s ../dummy_audio/dummyaudio.so plugins/
    ln -s ../rsp_hle/mupen64_hle_rsp_azimer.so plugins/

* linker command
  * remove '-z execstack', '-export-dynamic'

* Deal with some kind of bug between our 7zip code and Macports's zlib code, 
such
that you can only build mupen64plus with Macports if you eliminate
/opt/local/include/zconf.h

If all that is done, theoretically, the core without the dynarec and glN64 
should
build from trunk using 'make NO_ASM=1 all'.

Original comment by smuck...@gmail.com on 21 Aug 2008 at 12:46

[GoogleCodeExporter]

Note: make all should work on x86 OSX now if the system has the proper 
dependencies. The dynarec should also work.

There are current OSX issues in the form of plugins that don't compile / work 
properly.

Rice Video needs ebx removed from its inline assembly blocks as ebx is reserved 
on 
x86 OSX.

Blight input has threading issues (input may not work in GUI mode), but this 
seems 
to be an SDL issue, not a mupen issue. Not 100% sure if we can work around or 
its 
better to just wait on SDL.

Jttl Audio won't compile till be flag the OSS components as OSX is not an OSX 
platform (there may be a patch for this not yet applied to trunk).

Gilde64 won't compile (Not sure why).

We still have core endianness issues as Mupen on PPC on either Linux and OSX 
appears to be non-functional. Again details are sketchy.

Original comment by sknau...@wesleyan.edu on 11 Sep 2008 at 6:04

• Changed state: Started

[GoogleCodeExporter]

Just an update, Rice and Glide now compile.

OSX issues on x86 are basically limited to sync issues with audio and the SDL 
input 
issues. 

There are still some core endianness issues as Mupen on PPC on either Linux and 
OSX 
appears to be non-functional.

Original comment by sknau...@wesleyan.edu on 23 Sep 2008 at 6:36

[GoogleCodeExporter]

Here's a small patch to make compilation and installation work out-of-the-box 
on OS
X. Shouldn't break other platforms.

Original comment by auria...@gmail.com on 16 Dec 2008 at 4:13

Attachments:

• mupen2.patch

[GoogleCodeExporter]

I have modified your patch and committed the changes.  Please test to verify 
that my
modified patch works correctly on OSX.

Original comment by richard...@gmail.com on 19 Dec 2008 at 12:11

[GoogleCodeExporter]

It works, thanks

Original comment by auria...@gmail.com on 19 Dec 2008 at 12:33

[GoogleCodeExporter]

Excellent.  Can we close this issue report or are there remaining problems?

Original comment by richard...@gmail.com on 19 Dec 2008 at 12:36

[GoogleCodeExporter]

There are remaining issues (mainly input + GTK), but they can probably go 
elsewhere.
Especially since slougi partially fixed them in his branch

Original comment by auria...@gmail.com on 19 Dec 2008 at 12:41

[GoogleCodeExporter]

Okay, let's kill this 'laundry list' issue report and open others for the 
remaining
GTK/input problems.

Original comment by richard...@gmail.com on 19 Dec 2008 at 12:48

• Changed state: Fixed