45 replies to this topic

[collimarco]

Hi!

I've followed the instructions at http://trac.wildfire...atestReleaseMac

Everything works ok until I launch test.app in binaries/system by double-clicking on it in Finder.

The following error is raised:

Process:     	test [27822]
Path:            /Users/USER/Desktop/*/test.app/Contents/MacOS/test
Identifier:      test
Version:     	??? (???)
Code Type:   	X86-64 (Native)
Parent Process:  launchd [115]

Date/Time:   	2011-12-24 15:27:50.293 +0100
OS Version:      Mac OS X 10.7.2 (11C74)
Report Version:  9

Interval Since Last Report:          576845 sec
Crashes Since Last Report:       	11
Per-App Crashes Since Last Report:   5
Anonymous UUID:                      F75B22E4-9D31-45C7-8778-5E5D5339F0F3

Crashed Thread:  0

Exception Type:  EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000002, 0x0000000000000000

Application Specific Information:
dyld: launch, loading dependent libraries

Dyld Error Message:
  Library not loaded: @executable_path/libmozjs185-ps-release.1.0.dylib
  Referenced from: /Users/USER/Desktop/*/test.app/Contents/MacOS/test
  Reason: image not found

Binary Images:
   	0x107fe9000 -        0x10856eff7 +test (??? - ???) <16392DD5-A634-3FA6-95D8-7E3C60DB64C1> /Users/USER/Desktop/*/test.app/Contents/MacOS/test
   	0x1088da000 -        0x108905fff  com.apple.audio.OpenAL (1.5.1 - 1.5.1) <5B954EC6-08B6-3255-932C-DDAB908E72F4> /System/Library/Frameworks/OpenAL.framework/Versions/A/OpenAL
   	0x108917000 -        0x10894bfe7 +libjpeg.8.dylib (12.0.0 - compatibility 12.0.0) <91678CF3-F9A9-3A56-A2E8-32B503616BA9> /opt/local/lib/libjpeg.8.dylib
   	0x108953000 -        0x108972fff +libpng15.15.dylib (20.0.0 - compatibility 20.0.0) <48C87023-FB13-393C-8FD4-DE4F1803ECA3> /usr/X11/lib/libpng15.15.dylib
   	0x10897d000 -        0x108990fff +libz.1.dylib (1.2.5 - compatibility 1.0.0) <FE5409A4-0190-3939-9A83-9CF4BEFAEA0C> /opt/local/lib/libz.1.dylib
    0x7fff67be9000 - 	0x7fff67c1dac7  dyld (195.5 - ???) <4A6E2B28-C7A2-3528-ADB7-4076B9836041> /usr/lib/dyld
    0x7fff91b64000 - 	0x7fff91b73ff7  com.apple.opengl (1.7.5 - 1.7.5) <2945F1A6-910C-3596-9988-5701B04BD821> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL

Model: MacBookPro8,2, BootROM MBP81.0047.B24, 4 processors, Intel Core i7, 2 GHz, 4 GB, SMC 1.69f1
Graphics: AMD Radeon HD 6490M, AMD Radeon HD 6490M, PCIe, 256 MB
Graphics: Intel HD Graphics 3000, Intel HD Graphics 3000, Built-In, 384 MB
Memory Module: BANK 0/DIMM0, 2 GB, DDR3, 1333 MHz, 0x80CE, 0x4D34373142353737334448302D4348392020
Memory Module: BANK 1/DIMM0, 2 GB, DDR3, 1333 MHz, 0x80CE, 0x4D34373142353737334448302D4348392020
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0xD6), Broadcom BCM43xx 1.0 (5.100.98.75.18)
Bluetooth: Version 4.0.1f4, 2 service, 11 devices, 1 incoming serial ports
Network Service: Ethernet, Ethernet, en0
Serial ATA Device: APPLE SSD TS128C, 121,33 GB
Serial ATA Device: MATSHITADVD-R   UJ-8A8
USB Device: FaceTime HD Camera (Built-in), apple_vendor_id, 0x8509, 0xfa200000 / 3
USB Device: hub_device, 0x0424  (SMSC), 0x2513, 0xfa100000 / 2
USB Device: BRCM2070 Hub, 0x0a5c  (Broadcom Corp.), 0x4500, 0xfa110000 / 5
USB Device: Bluetooth USB Host Controller, apple_vendor_id, 0x821a, 0xfa113000 / 6
USB Device: Apple Internal Keyboard / Trackpad, apple_vendor_id, 0x0246, 0xfa120000 / 4
USB Device: hub_device, 0x0424  (SMSC), 0x2513, 0xfd100000 / 2
USB Device: Elements 1042, 0x1058  (Western Digital Technologies, Inc.), 0x1042, 0xfd120000 / 4
USB Device: IR Receiver, apple_vendor_id, 0x8242, 0xfd110000 / 3

Any ideas?
Thanks ;)

[atopuzov]

collimarco, on 24 December 2011 - 02:35 PM, said:

I've followed the instructions at http://trac.wildfire...atestReleaseMac
Everything works ok until I launch test.app in binaries/system by double-clicking on it in Finder.

Hi,

I just successfully compiled and run the game.
Instead of double-clicking on the test.app use Terminal to go to the binaries/system directory and copy pyrogenesis.app/Contents/MacOS/pyrogenesis to binaries/system
eg. if you are in binaries/system:

cp pyrogenesis.app/Contents/MacOS/pyrogenesis .

and now run the game from terminal with:

./pyrogenesis

If you don't get full screen and the colors are weird it's because of the incompatibility of libSDL 1.2 and Mac OS X Lion.
I have compiled it with SDL 1.3 (with some minor modifications due to errors eg. [1], but since they are more of hacks just to see if it will compile some of the mouse/keyboard controls are misfiring ) and with it everything with the graphics is OK.
I haven't compiled in the atlas (scenario editor) support because I didn't what to fiddle with wxwidgets
If you want I can provide the binaries (which are unofficial of course), the only constraint is that they will run only on 10.7 64bit systems (due to my environment setup at the compile time)


[1] Link1

Edited by atopuzov, 28 December 2011 - 12:06 PM.

[JuliusColtranePille]

could you please upload an employable version of the game? ... i am not really able to compile it myself...

would be cool, thankyou!

[atopuzov]

JuliusColtranePille, on 25 December 2011 - 11:19 AM, said:

could you please upload an employable version of the game? ... i am not really able to compile it myself...

would be cool, thankyou!

Hi,

Download the data archive (0ad-r10803-alpha-unix-data) unpack it. You should now have a folder named something like 0ad-r10803-alpha now open it and download the NEW BINARIES and unpack them in the binaries folder (0ad-r10803-alpha/binaries). Now open the binaries dir and double click the pyrogenesis.app. The game should start hopefully. If you get an error please c&p it here. Binaries are tested on 10.7 compiled in 64bit (IMHO they should also run on 10.6). Scenario editor is not provided (just me being lazy). There are some problems with mouse zooming in/out (due to SDL 1.2 and 1.3 quick fix by me).

Update new set of binaries are uploaded with patched SDL 1.2 and Scenario editor!

Best regards
Aleksandar

Edited by atopuzov, 28 December 2011 - 12:33 PM.

[collimarco]

Thank you very much atopuzov!

When I copy the file it works! As you said it doesn't start in fullscreen mode.

So I tried your binaries and they work. The game starts in fullscreen mode! The only problem: "Audio has been disabled due to a problem with OpenAL in Mac OS X". Do you have the same problem?

Furthermore during the game a lot of errors appear on the screen (they say many things can't be loaded). Is that normal?

Edited by collimarco, 25 December 2011 - 05:59 PM.

[atopuzov]

collimarco, on 25 December 2011 - 03:21 PM, said:

Thank you very much atopuzov!

When I copy the file it works! As you said it doesn't start in fullscreen mode.

So I tried your binaries and they work. The game starts in fullscreen mode! The only problem: "Audio has been disabled due to a problem with OpenAL in Mac OS X". Do you have the same problem?

Furthermore during the game a lot of errors appear on the screen (they say many things can't be loaded). Is that normal?

Hi,

I also get the error that the audio is disabled due to OpenAL but haven't tried to enable it to see what seems to be happening.
For the errors during the game can you go into the ~/.config/0ad/logs and look at the files and c&p the error (and write what scenario have you chosen, and which binaries are you using mine or yours). I haven't tried playing for a long time so I haven't encountered any. The only errors I got was when I forgot to put the libCollada.dylib file in the right place, which should be in the same directory as the pyrogenesis.app.

Best regards
Aleksandar

[wraitii]

I've actually fixed that in my release. It has to do with the fact that you're trying to use dynamic libraries (dylib) on MacOSX, and the game can't find them because they are not where they "should" be. You have to run a script. Try searching "Mac os X deployment dylib" for more information.

[feneur]

Sound is indeed disabled on Mac for now. We have a rewrite of the sound system underway that should solve that problem. Unfortunately the programmer working on it wasn't able to finish his work in time for Alpha 8. If things go well it should be included in Alpha 9 though and Mac users should finally be able to hear the sounds

[atopuzov]

wraitii, on 25 December 2011 - 10:01 PM, said:

I've actually fixed that in my release. It has to do with the fact that you're trying to use dynamic libraries (dylib) on MacOSX, and the game can't find them because they are not where they "should" be. You have to run a script. Try searching "Mac os X deployment dylib" for more information.

Hi,

All libraries and executables are 'modified' so the search path is @executable_path/ (install_name_tool)
eg.:

otool -L pyrogenesis.app/Contents/MacOS/pyrogenesis 
pyrogenesis.app/Contents/MacOS/pyrogenesis:
	/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/OpenAL.framework/Versions/A/OpenAL (compatibility version 1.0.0, current version 1.0.0)
	@executable_path/libjpeg.8.dylib (compatibility version 12.0.0, current version 12.0.0)
	/usr/X11/lib/libpng15.15.dylib (compatibility version 20.0.0, current version 20.0.0)
	/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
	@executable_path/libmozjs185-ps-release.1.0.dylib (compatibility version 1.0.0, current version 1.0.0)
	@executable_path/libvorbisfile.3.dylib (compatibility version 7.0.0, current version 7.4.0)
	@executable_path/libboost_signals-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
	@executable_path/libboost_filesystem-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
	@executable_path/libboost_system-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
	@executable_path/libenet.1.dylib (compatibility version 2.0.0, current version 2.3.0)
	/usr/lib/libcurl.4.dylib (compatibility version 7.0.0, current version 7.0.0)
	@executable_path/libnvcore.dylib (compatibility version 0.0.0, current version 0.0.0)
	@executable_path/libnvmath.dylib (compatibility version 0.0.0, current version 0.0.0)
	@executable_path/libnvimage.dylib (compatibility version 0.0.0, current version 0.0.0)
	@executable_path/libnvtt.dylib (compatibility version 0.0.0, current version 0.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
	@executable_path/libSDL-1.3.0.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libxml2.2.dylib (compatibility version 10.0.0, current version 10.3.0)
	/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 52.0.0)

But libCollada.dylib is loaded from the app itself by dlopen and I have looked at the source code where does the app try to find it. But for me it works if it's in the folder where the pyrogenesis.app resides and not in the @executable_path which is in fact pyrogenesis.app/Contents/MacOS.

Best regards
Aleksandar

[historic_bruno]

atopuzov, on 25 December 2011 - 11:13 PM, said:

But libCollada.dylib is loaded from the app itself by dlopen and I have looked at the source code where does the app try to find it. But for me it works if it's in the folder where the pyrogenesis.app resides and not in the @executable_path which is in fact pyrogenesis.app/Contents/MacOS.

I believe when you run an app bundle, the working directory is set to the directory where the bundle is located, not where the binary itself is located, it's a special OS X thing, so that's why it will search and find libraries there. At least that's what it does by default, I don't know if the behavior can be changed.

[atopuzov]

feneur, on 25 December 2011 - 10:18 PM, said:

Sound is indeed disabled on Mac for now. We have a rewrite of the sound system underway that should solve that problem. Unfortunately the programmer working on it wasn't able to finish his work in time for Alpha 8. If things go well it should be included in Alpha 9 though and Mac users should finally be able to hear the sounds

Hi,

Great news indeed. While you are at it could you possibly check out the compatibility with libSDL 1.3 since 1.2 doesn't run well on Mac OS X 10.7 Lion (no fullscreen, and some glitches with the colors). The error I have encountered was to do with SDLK_LAST not being available (I just added a define for it) and something to due with sync settings which I disabled (can't really remember now). Just try to compile it with libSDL 1.3 and you get the errors.



Best regards
Aleksandar

[atopuzov]

historic_bruno, on 25 December 2011 - 11:22 PM, said:

I believe when you run an app bundle, the working directory is set to the directory where the bundle is located, not where the binary itself is located, it's a special OS X thing, so that's why it will search and find libraries there.

Hi,

Yes that's correct for opening the libraries with dlopen and likes. But for linked libraries you change the locations with install_name_tool to be sure that the right libraries are found when deploying Mac OS X applications. (eg. check the Mac OS X QT deployment guide). So for 1. you have to add it in the source code of the application to look for it at the right place.
eg. for QT

#if defined(Q_OS_MAC)
        QDir exec_dir = QDir(QCoreApplication::applicationDirPath());
#endif

And now you have exec_dir (which is set at the location of the executable) and you can now use it to find whatever you need. So when you distribute the app you have everything bundled up in one app.bundle.

Best regards
Aleksandar

[historic_bruno]

atopuzov, on 25 December 2011 - 11:22 PM, said:

Great news indeed. While you are at it could you possibly check out the compatibility with libSDL 1.3 since 1.2 doesn't run well on Mac OS X 10.7 Lion (no fullscreen, and some glitches with the colors)

There may be a patch for SDL 1.2 that fixes the Lion fullscreen issue, which would be worth testing. Otherwise if we use a 1.3 development version on OS X, we have a whole different set of possible bugs to work around and it diverges from the Linux and Windows paths. Of course there are other problems with SDL 1.2, namely the GL context gets lost when switching between windowed and fullscreen in Windows and OS X, which requires some changes on our end.

[atopuzov]

historic_bruno, on 25 December 2011 - 11:44 PM, said:

There may be a patch for SDL 1.2 that fixes the Lion fullscreen issue, which would be worth testing. Otherwise if we use a 1.3 development version on OS X, we have a whole different set of possible bugs to work around and it diverges from the Linux and Windows paths. Of course there are other problems with SDL 1.2, namely the GL context gets lost when switching between windowed and fullscreen in Windows and OS X, which requires some changes on our end.

Hi,

Can you provide a link for the patch since I've seen a few and haven't had the time to read trough which is the latest and fixes the problems. It's not only the fullscreen issue, I can live with windowed mode but all the colors are wrong and there are some image tearing. Since nobody knows when SDL 1.3 will be released I get your point (we saw a release of duke nukem so we can only hope) of having a one version of library on Mac and an other on Win/Lin. It would hard to maintain.

Best regards
Aleksandar

[historic_bruno]

Here's the SDL 1.2 patch I mentioned. It would be nice if we could make a script to get all OS X dependencies (for developers of course, not the average user), then it could apply that patch to SDL before building it.

atopuzov, on 25 December 2011 - 11:59 PM, said:

It's not only the fullscreen issue, I can live with windowed mode but all the colors are wrong and there are some image tearing

Hmm I haven't noticed this at all, though I only have a VM for testing. Can you post a screenshot of what you are seeing?

[jdm]

Interestingly enough, on Snow Leopard the full screen mode works but windowed mode is completely broken.

[Chakakhan]

historic_bruno, on 26 December 2011 - 12:40 AM, said:

Here's the SDL 1.2 patch I mentioned.

Yes, that patch works. The fix isn't in an official release, so it is problematic for our OS/X users.

Ben - as you, Phillip and I discussed, the best solution is to include all the 3rd party libs in an app bundle so that OS/X users could just download and run the game without worrying about supporting libraries. I think we should try to do this for Alpha 9. It would really make help us in supporting Mac versions going forward and also allow less technical Mac users to play the game.

Cheers

jdm, on 26 December 2011 - 04:06 AM, said:

Interestingly enough, on Snow Leopard the full screen mode works but windowed mode is completely broken.

Yes, the Cocoa calls to set the video mode changed and this caused some issues. The full solution is to add code to detect the desktop resolution and to include the proper patched version of SDL in our release somehow. This will solve the full screen / windowed mode problems.

Cheers

[wraitii]

Note that the Collada loading problem can be fixed in a more "convergent" way by simply adding a bit of platform-dependant code. I did so in my release: I Changed the DLL loader function LoadAnyVariant to this

static void* LoadAnyVariant(const CStr& name, std::stringstream& errors)
{
	for(size_t idxSuffix = 0; idxSuffix < ARRAY_SIZE(suffixes); idxSuffix++)
	{
		for(size_t idxExtension = 0; idxExtension < ARRAY_SIZE(extensions); idxExtension++)
		{			
			CStr filename = GenerateFilename(name, suffixes[idxSuffix], extensions[idxExtension]);

			// Here's what I added
			// this should ensure Collada is properly loaded.
			#if OS_MACOSX
			if (name == "Collada" || name == "AtlasUI")
				filename = "@executable_path/../Frameworks/" + filename;
			#endif

			// we don't really care when relocations take place, but one of
			// {RTLD_NOW, RTLD_LAZY} must be specified. go with the former because
			// it is safer and matches the Windows load behavior.
			const int flags = RTLD_LOCAL|RTLD_NOW;
			void* handle = dlopen(filename.c_str(), flags);
			if(handle)
				return handle;
			else
				errors << "dlopen(" << filename << ") failed: " << dlerror() << "; ";
		}
	}

	return 0;	// none worked
}

(note that I link to "Frameworks" because I copied there every library needed for the game.
Linking even the Data in it can be done too, but requires slightly greater changes.

I also report the fact that going from FS to windowed mode crashes. Though the fullscreen mode works correctly.


As for the release, indeed linking every library with the app bundle is needed and not too hard (a simple copy and scripting issue, which is fairly straightforward.) Note that some of the libraries used are relying on other libraries, so you have to make sure you modify everything (not only the executable and the libraries, but the calls between libraries).
Putting the Data inside the game bundle might not be a priority for now, as long as the game works when you start it.

Edited by wraitii, 26 December 2011 - 08:03 AM.

[Chakakhan]

wraitii, on 26 December 2011 - 07:17 AM, said:

As for the release, indeed linking every library with the app bundle is needed and not too hard (a simple copy and scripting issue, which is fairly straightforward.) Note that some of the libraries used are relying on other libraries, so you have to make sure you modify everything (not only the executable and the libraries, but the calls between libraries).
Putting the Data inside the game bundle might not be a priority for now, as long as the game works when you start it.

Cool, hopefully you can help us figure out the best way to implement this.

Cheers

[wraitii]

I'm going to be away for a week, so won't be able to help much during this time, but the Idea is that you need to add a "copy file" phase and a "run script" phase to your Xcode projects. In the copy file phase, you'd copy every single dylib needed (I record 25). In the run script, you'll have to change the links so that it works.

You may want to take a look at this. I don't think it can compile as such, and it's not a perfectly up-to-date project, but it'll give you the idea.