Menu
What's new
By:
Filters

Who wants to help with a osx port?

S

sturmen

New member
I'd love to help beta test! I have two Intel Macs available:
Macbook (High-end white)
iMac (high-end 24", right before the speedup… 2.4 GHz)
 
T

Tillin9

Mupen64Plus Dev.
We have Rice and Glide now working on OSX (x86/x86_64) also. Rice has a number of issues (not related to OSX) so don't be overzealous in bug reporting there. We also fixed the crash on ROM close.

I would love for someone (ideally with 10.4.x and 10.5.5) to test out
Issue 146. http://code.google.com/p/mupen64plu...Status Priority Stars Milestone Owner Summary

Specifically I want to know if this is just a libiconv not installed issue and if -dylib_file has any negative effect on OSX < 10.4.
 
T

thatmariolover

New member
Update:

I am still encountering a build error:

-L/usr/X11/lib -lfreetype -lz -Wl,-framework,CoreServices -Wl,-framework,ApplicationServices -o blight_input.so
ld: library not found for -lSDL_ttf
collect2: ld returned 1 exit status
make[1]: *** [blight_input.so] Error 1
make: *** [plugins/blight_input.so] Error 2
mac-pro:trunk ericherr$ sudo port install lsdl_ttf
Click to expand...

Shouldn't it be looking for SDL_ttf and not lSDL_ttf? Anyway, not sure if anybody can shine some light on this latest issue.


The issues below were resolved after I managed to deactivate the offending libraries using 'sudo port deactivate [library/version]' which in turn allowed me to install the libraries correctly:

So, I followed the instructions from here:

http://code.google.com/p/mupen64plus/wiki/MacOSXInstructions

However, I am getting a build error:

"ld: cycle in dylib re-exports with /usr/X11R6/lib/libGL.dylib"
Click to expand...

After doing some googling I found this help page from Apple:

http://developer.apple.com/qa/qa2007/qa1567.html

Background

The linker on Mac OS X v.10.5 searches -L paths for indirect libraries and in doing so it finds two copies of libGL.dylib. One in /usr/X11/lib and the other in /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries and this causes a cycle.

This is a side effect of various linker improvements in Leopard, which we may be able to mitigate in a future release.

Back to Top
Workaround

You can overcome this problem by providing the -dylib_file option to the linker. The -dylib_file option is described as:

-dylib_file install_name:file_name
Specifies that a dynamic shared library is in a different location than its standard location.
Use this option when you link with a library that is dependent on a dynamic library, and the
dynamic library is in a location other than its default location. install_name specifies the path
where the library normally resides. file_name specifies the path of the library you want to use
instead. For example, if you link to a library that depends upon the dynamic library libsys
and you have libsys installed in a nondefault location, you would use this option:
-dylib_file /lib/libsys_s.A.dylib:/me/lib/libsys_s.A.dylib.
Click to expand...

I'm having trouble understanding what exactly I need to do to get this working.

Kind of a big edit:

Before I had followed the instructions on that page, I had attempted to install some of the libraries on my own. Unfortunately, this means I didn't use the no_x11 variant which I assume is what is causing my troubles.

Now when I try to install the libraries (using sudo port install pango +no_x11 cairo +quartz+pdf+no_x11 gtk2 +quartz libsdl_ttf), I get an error:

Target org.macports.activate returned: Image error: Another version of this port (name/version of library here) is already active.
Click to expand...

Is there an easy way to remove those libraries to install them properly?
Click to expand...
 
Last edited:
R

roger6106

New member
The x11 version of some of these items being installed appears to be what's causing your problem. The command "sudo port uninstall pango cairo gtk2" should remove the x11 versions.

Macports may tell you that it can't remove those programs due to them being dependencies. If so, remove the program that depends on them (using sudo port uninstall [program name]). After all this is done you should be able to install the non-x11 versions.
 
Last edited:
T

thatmariolover

New member
roger6106 said:
The x11 version of some of these items being installed appears to be what's causing your problem. The command "sudo port uninstall pango cairo gtk2" should remove the x11 versions.

Macports may tell you that it can't remove those programs due to them being dependencies. If so, remove the program that depends on them (using sudo port uninstall [program name]). After all this is done you should be able to install the non-x11 versions.
Click to expand...

Yeah, I removed all of the dependencies using the uninstall command and reinstalled the non x11 versions. However, I'm still encountering this build error:

ld: library not found for -lSDL_ttf
collect2: ld returned 1 exit status
make[1]: *** [blight_input.so] Error 1
make: *** [plugins/blight_input.so] Error 2
Click to expand...
 
T

Tillin9

Mupen64Plus Dev.
surmen: Did you install the gtk-dev packages? The build script uses pkg-config to get the gtk+-2.0 C flags and library flags. Is pkg-config installed and GTK registering? What does

pkg-config gtk+-2.0 --cflags

give on the terminal? If you can't get GTK configured, you can manually set them in pre.mk.

thatmariolover: That error just means SDL_tff and its development package are not installed. SDL has a few smaller optional libraries. Blight requires SDL_tff.

To all OSX testers, if you can please install SDL 1.3 from their svn or development snapshots. I believe the no keyboard input in GUI mode bug is purely an SDL issue and already solved on their upstream. If we can confirm this is the case, someone could theoretically make an Intel OSX app bundle with SDL 1.3 statically included.
 
S

sturmen

New member
Tillin9 said:
surmen: Did you install the gtk-dev packages? The build script uses pkg-config to get the gtk+-2.0 C flags and library flags. Is pkg-config installed and GTK registering? What does

pkg-config gtk+-2.0 --cflags

give on the terminal? If you can't get GTK configured, you can manually set them in pre.mk.
Click to expand...
Code: 
macbook-3:~ sturmen$ pkg-config gtk+-2.0 --cflags
Package gtk+-2.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `gtk+-2.0.pc'
to the PKG_CONFIG_PATH environment variable
printout from iTerm. How do I do that? I know where "gtk+-2.0.pc" is. But where do I type that in?
 
Last edited:
T

thatmariolover

New member
Tillin9 said:
thatmariolover: That error just means SDL_tff and its development package are not installed. SDL has a few smaller optional libraries. Blight requires SDL_tff.

To all OSX testers, if you can please install SDL 1.3 from their svn or development snapshots. I believe the no keyboard input in GUI mode bug is purely an SDL issue and already solved on their upstream. If we can confirm this is the case, someone could theoretically make an Intel OSX app bundle with SDL 1.3 statically included.
Click to expand...

I already worked past the SDL_ttf bug, so it's compiling and running.

As for installing SDL 1.3 to fix the lack of keyboard input, that's possible. I've been using a 360 controller so I haven't had that issue. However, when I try to install SDL 1.3 using the Mac OS X instructions packaged with it, I get errors about it not finding a config file.
 
Last edited:
T

Tillin9

Mupen64Plus Dev.
sturmen: You can manually add to PKG_CONFIG_PATH,

PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/my/additional/config

You can add an export PKG_CONFIG_PATH line somewhere to your shell's profile, however, this suggests something is wrong with your install.

thatmariolover: What error do you get? Maybe someone here can help.
 
T

thatmariolover

New member
So I was reading here:
http://www.libsdl.org/svn.php

And I downloaded 1.3 from the svn using Terminal:
svn co http://svn.libsdl.org/trunk/SDL

That comes with README.MacOSX, which says:

==============================================================================
Using the Simple DirectMedia Layer with Mac OS X
==============================================================================

These instructions are for people using Apple's Mac OS X (pronounced
"ten").

From the developer's point of view, OS X is a sort of hybrid Mac and
Unix system, and you have the option of using either traditional
command line tools or Apple's IDE Xcode.

To build SDL using the command line, use the standard configure and make
process:

./configure
make
sudo make install

You can also build SDL as a Universal library (a single binary for both
PowerPC and Intel architectures), on Mac OS X 10.4 and newer, by using
the fatbuild.sh script in build-scripts:
sh build-scripts/fatbuild.sh
sudo build-scripts/fatbuild.sh install
This script builds SDL with 10.2 ABI compatibility on PowerPC and 10.4
ABI compatibility on Intel architectures. For best compatibility you
should compile your application the same way. A script which wraps
gcc to make this easy is provided in test/gcc-fat.sh

To use the library once it's built, you essential have two possibilities:
use the traditional autoconf/automake/make method, or use Xcode.
Click to expand...

My guess is I just have no clue what I'm doing and I'm missing a step that should be self explanatory to somebody who compiles regularly.

What should I be doing now that I have it checked out?

I tried just make clean ; make all. That returns:
make: *** No rule to make target `clean'. Stop.
make: *** No rule to make target `all'. Stop.

Which I assume is because there's no 'makefile'.

If I try using:
sh build-scripts/fatbuild.sh
sudo build-scripts/fatbuild.sh install

I get this returned for the first line:
sh: ../../configure: No such file or directory

And this for the second:
sh /Users/username/sdlinstall/SDL/build-scripts/../build-scripts/mkinstalldirs /usr/local/bin
/usr/bin/install -c -m 755 build/x86/sdl-config /usr/local/bin/sdl-config
install: build/x86/sdl-config: No such file or directory
 
Last edited:
T

thatmariolover

New member
That did the trick, SDL 1.3 is installed. Will test keyboard input.

Unfortunately, now that I installed 1.3, I get the following error upon building Mupen:

main/main.c:826: warning: passing argument 1 of ‘SDL_SetEventFilter’ from incompatible pointer type
main/main.c:826: error: too few arguments to function ‘SDL_SetEventFilter’
make: *** [main/main.o] Error 1
 
Last edited:
D

dgm

New member
^ I couldn't figure out how to compile SDL_ttf with SDL 1.3. Maybe you're forgetting about this dependancy?

Anyone know how to compile SDL_ttf for the newest SDL?
 
You must log in or register to reply here.

Top