Shin_Gouki
New member
wow the screens look nice!
-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
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"
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.
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.
Is there an easy way to remove those libraries to install them properly?
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.
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
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.
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
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.
==============================================================================
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.