Nate's Programming Blog

I have been fighting to get FCEUX installed on my iMac ever since I got it.  It came with Mountain Lion and I was able to install FCEUX on Lion without issue, but Mountain Lion was a completely different story.  I initially tried installing XQuartz (make sure to do this first if you have not already) and then FCEUX using homebrew as I had done before.

brew update
brew doctor
brew install fceux

But got the following error:

==> Downloading http://downloads.sourceforge.net/fceultra/fceux-2.1.5.src.tar.bz2
Already downloaded: /Library/Caches/Homebrew/fceux-2.1.5.tar.bz2
==> Patching
patching file src/drivers/sdl/SConscript
==> scons
env.ParseConfig(‘pkg-config –cflags –libs gtk+-2.0’)
File “/usr/local/Cellar/scons/2.2.0/libexec/scons-local/SCons/Environment.py”, line 1554:
return function(self, self.backtick(command))
File “/usr/local/Cellar/scons/2.2.0/libexec/scons-local/SCons/Environment.py”, line 596:
raise OSError(“‘%s’ exited %d” % (command, status))

After doing some research, I discovered that it was having issues finding the required X11 packages and was failing. I tried specifying

PKG_CONFIG_PATH=/opt/X11/lib/pkgconfig/ brew install fceux

But that also did not resolve the problem. I found someone else having the same issue as me on github and commented that I was having the same issue, but didn’t get back anything that worked, so I decided to go straight to source and see if I could compile and install it from the FCEUX site.

I downloaded the latest version 2.2.0 src tarball and read the “README-SDL.md”. The readme stated that it should be compiled and installed using scons, so I ran the scons command within the directory and got the same error again. So I decided to break into the SConscript file and see if I could figure out how to fix the error. I found the line that was running pkg-config on gtk+-2.0 from the error and added

PKG_CONFIG_PATH=/opt/X11/lib/pkgconfig/

to the front of the pkg-config command to see if that would work and to my surprise I got passed the error. The next error I received was that liblua could not be found. That was easy to fix by running

brew install lua

After that I ran scons again and to an even greater surprise it compiled without error. After that I was able to run scons install to install the binary and then ran fceux and it ran without error.

FCEUX running Super Mario Bros on Mac OS X Mountain Lion

When you do iPhone/iPad development and your client tests the app, sometimes issues arise that are not easily reproducible because they are specific to the user’s device.  When this happens, the easiest way to get a glimpse at what is going on is to retrieve the logs off of the device.  This is not a super simple process, so I felt it was necessary for me to provide some instructions that I can share anytime I need to have a client pull the logs.

Step One: Install the iPhone Configuration Utility

If you are on a mac, you can find the iPhone configuration utility here.  If you are on a PC, you can find the app here.  Install the application as you would install any application using the default settings.

Step Two: Launch the iPhone Configuration Utility.  You should see a window similar to below.

Step Three: Plug in your iPhone/iPad into your computer.

Select your device from the “Devices” list like below

Then select the console tab on the far right

Then use the application to reproduce the issue that you are having.  The console should update with information from the application.  Once you are done, select the “Save Console As…” button and save the file to an easy place to remember.  The last step is to email the console log file to the developer for review.

Note: At times I have experienced a blank console.  If this happens, try unplugging and replugging the device while the iPhone Configuration Utility is running and follow the steps again to get to the console.

So I ran into a mind numbing issue trying to archive one of my applications today.  Typically when I have a dependency on third party code or another project, I create a static library of that project and then add it as a sub project to my application.  When doing this you have to make sure the header files are copied to the public folder and you have to add the path to the “Header Search Paths” so that it can find them at compile time.  It seems that the standard location for these files are in /usr/local/include because that is the default folder Xcode sets when you create the static library project.  I typically add the name of the project to the end of the path, because I typically reference multiple sub projects.

After you have done this the application will build with the new sub project and you will be able to run it in the simulator and the device without issue.  That is until you try and archive your application for distribution.  First it will magically stop compiling until you add “$(BUILD_ROOT)/../InstallationBuildProductsLocation/usr/local/include” to your Header Search Paths.  This is because when archiving it builds from the intermediate files directory rather than the products directory and it will not be able to find the header files it was able to find just fine when building normally.  It will even build just fine when you select build for archiving, because it only builds from the intermediate files directory when you specifically choose to archive.  As you can imagine, this is very frustrating if you do not know this fact.

So after adding “$(BUILD_ROOT)/../InstallationBuildProductsLocation/usr/local/include” to the header search path the application successfully archived, but the result was a generic Xcode archive rather than an iOS application archive.  After combing stack overflow for some time, I discovered when you link to the public header files this way it also drops them into the archive at the same level as the Applications directory.  This causes Xcode to see the archive as a multiple module archive and not an application archive.  I found that someone had discovered this on stack overflow here, but I did not like any of the solutions that were provided.

Therefore I started looking around and noticed that there are pre-action and post-action sections in the scheme when archiving and you can run arbitrary shell scripts.  I decided then to add a pre-action that removed the usr directory prior to archiving.  It looked like this when I was done.

Archive Pre-Actions

This fixed the issue and made it so that I could archive and distribute the application.  As I was looking around and researching the issues I was running into, I noticed that I setup the sub-project pretty much the same way that everyone else does, so why would Xcode seem to have this serious of a problem.  I understand that many people do not link to dependencies in a good way and copy and paste code into their projects, but this seems like the preferred and best way to handle dependencies outside of compiling and linking to the static frameworks rather than the projects themselves, which has its benefits and challenges as well.  I just keep waiting for the people at Apple to get their crap together and provide an IDE that is reliable and easy to use.  We should not have to have in depth, behind the scenes knowledge of how the compiler works and the build process works just to be able to build and distribute an application.  That is at least my opinion.