Forum Replies Created
June 17, 2007 at 6:45 am in reply to: Help installing onto Mac OS X (and app build request) #36090
It would appear that scorched is linked against version 1.2.0 of the OpenGL library, but Mac OS X only provides version 1.0.0. I guess you’ll have to install X11. Don’t forget to remove the link first.June 17, 2007 at 6:42 am in reply to: Help installing onto Mac OS X (and app build request) #36089
The reason that the problem is occurring is because of the way shared libraries are handled in Unix-like operating systems. In most Unix-like systems, linking with a shared library causes its path to be placed in the binary, so that it must appear in that same location before the binary can be run. The problem, of course, is that in a different system it might not be there, or it might have a different name, or it might not exist at all. Mac OS X gets around this by allowing a shared library to specify that its path should be stored relative to the binary.
The version of Scorched3D that you are trying to run seems to be linked to the OpenGL shared library (libGL.1.dylib) that is provided by X11 (/usr/X11R6). This means that it will look in /usr/X11R6/lib for libGL.1.dylib when someone tries to run it. If X11 is not installed, that file probably doesn’t exist, so it fails. The sequence of commands that I provided are intended to trick the dynamic loader into using the OpenGL library that is provided by the OpenGL framework, which comes with Mac OS X.
This problem is typical of binaries built with autoconf on the Mac, and this sort of issue is my biggest problem with fink. It tends to create dependencies on the packages within fink, thus creating dependencies on fink itself. While I don’t have a particular problem with having fink installed on my system (other than the extra space it would take up), I do have a problem requiring others to have fink installed on their systems.
MacPorts deals with this issue a bit more reasonably in my opinion, by providing relocatable framework builds for many packages. A framework can be built, linked to, and then included in the application bundle, thus eliminating external dependencies (but increasing the size of the application, sometimes substantially).
For the record, I do have X11 installed.June 17, 2007 at 6:21 am in reply to: Help installing onto Mac OS X (and app build request) #36087
There was supposed to be a space between OpenGL and /usr. It appears that the line break caused a bit of confusion. You can delete the libGL.1.dylib alias that was created in your home folder, and rerun that last command with the space in there.
If you have Tiger, X11 should be installable from your Tiger DVD. I don’t remember whether that applies to Panther or not.June 16, 2007 at 9:04 pm in reply to: Help installing onto Mac OS X (and app build request) #36085
Mac OS X 10.4 comes with OpenAL, so you shouldn’t need to download it separately if you have 10.4 or later. If you do not have 10.4 or later, you will need OpenAL.
It would appear that the version that you have has a dependency on X11. You might be able to get around that with the following:
sudo mkdir /usr/X11R6
sudo mkdir /usr/X11R6/lib
sudo ln -s /System/Library/Frameworks/OpenGL.framework/OpenGL /usr/X11R6/lib/libGL.1.dylib
Just make sure you don’t install X11 without first removing that link:
sudo rm /usr/X11R6/lib/libGL.1.dylib
Otherwise you might cause major problems, depending on how intelligently the X11 installer handles overwriting a link.June 16, 2007 at 8:10 am in reply to: Help installing onto Mac OS X (and app build request) #36083
X11 is no longer needed for the Mac version. You can create a /usr/local directory in any terminal, provided you have administrator access, using the command
sudo mkdir /usr/local
Note that this will fail if the directory already exists. Also note that it is hidden by default for a reason; an administrator can do some pretty significant damage to a system by messing around in there.
I’m not sure why, but I have been able to successfully run scorched directly from the disk image. I can only guess that it looked for its ‘share’ directory in the same directory as argv.
It looks like it wouldn’t take much to convert the code to use frameworks for everything, as long as autoconf is not needed. I still need to know what preprocessor macros are used, and what determines their value, before I can build a proper application bundle. I also need a full-size icon.June 14, 2007 at 2:46 am in reply to: Help installing onto Mac OS X (and app build request) #36080
I’m new here, so forgive me if I am supposed to create a new thread instead, or something like that…
I was wondering if there is a Universal build somewhere. I would be willing (and able) to make one, as well as a fully usable .app and associated XCode project files, but first I would need a configured tarball that supports frameworks. Obviously, autoconf has no direct support for them, so the necessary configurations would probably need to be done manually. I would also require an icon, preferably 128x128x32 PNG. In addition, I would need the program to be able to locate its share directory at ../Resources, relative to the executable.
If those accommodations cannot be made, I would be willing to package the current executable file in an application package, but I’d still need a Universal build, and an icon.