I’m doing some work on a project that is using PHP, and have been working on setting up some continuous integration build scripts to make sure that we have a shot at catching errors before they make their way to production.

Recently some unit tests were added for the “forgot password” code, which uses the mcryp

t libraries which are not installed by default on Mac OSX, so I was seeing this error:

So some quick Google searches, and I found a couple of blogs with “how to” install the library (links at the end of this post), and proceeded to get this done.

First step was to download the mcrypt from SourceForge at http://sourceforge.net/project/showfiles.php?group_id=87941

Once I had the file, I opened a command prompt and ran:

Next I ran configure, setting the appropriate flags for my envirionment (note – I didn’t do this for the other configures, probably would have been a good idea):

This sets up the make file, so you can run the next two commands:

Next to make the PHP library, I needed the PHP source files, so I went out and grabbed PHP 5.3.15 (since that’s the version I have when I run php -version) by going to http://us3.php.net/get/php-5.3.15.tar.bz2/from/a/mirror. Note that you can simply change the version number in that URL to get the version you need.

Once I had that I did the following:

This of course gave me an error about autoconf not being installed:

From there I installed autoconf by doing the following:

Then back to the php mcrypt folder and reran the phpize step to and finish building:

Finally an edit to the php.ini file which was simply to add the extension:

And of course a quick restart of Apache and the extension shows up and I can run my unit tests successfully.

Related posts:



Enhanced by Zemanta

I updated to OS X Lion a couple of days ago, and for the most part it was a smooth transition.

This is the first upgrade where Apple is using their App Store concept to distribute the OS, so it was a bit scary to hit “Purchase” and watch nothing happen for half an hour while Mac OS X 10.7 downloaded in the background.

There’s no real indication of anything going on unless you happen upon the “Purchase” tab in the App Store App (seems a bit redundant, doesn’t it?):

App Store purchased items
After the long download, there was a typical OS install (well maybe not that typical, since it just worked) that ran for nearly an hour. Once that was done there were a couple of minor housekeeping items (like loading Java again separately for some reason), but all in all not much looked different than before.

I was happily exploring features like “Launchpad” and “Mission Control“, when I stumbled on a weird problem. My mouse wheel was scrolling the browser in reverse. That is, it was working in the more natural direction: scrolling the wheel up moved the text upward, and down moved things down.

At first I thought I had some weird virus, but when I upgraded my other Mac, I found the same issue. So I did a couple of quick searches on the Apple site, and found some mentions of the issue.

Apparently somebody at Apple decided the way things scroll has been backward all this time, and made the mouse default the other direction. There were some how-to fix it, but they showed screen shots from a Mac with an Apple mouse, which has a few more settings than what I saw:

Default Mouse Settings

While set this way, moving the mouse wheel up made the scroll bar go down, which was confusing to me, since that was what I always thought the wheel was tied to. But it did make the text scroll in the direction of the mouse wheel.

After a very short period, I got used to scrolling that way, but soon realized I’d be in trouble if I had to go to a Windows machine, so I simply unchecked the “when using gestures to scroll or navigate move content in the direction of finger movement” and I was back to “normal”.

Mouse settings

I’m sure at some point I’ll probably be sorry (like when I get an actual touch-screen Mac), but hopefully by then Apple will have a setting that will just make my mouse act like it does in Windows, and allow touch to act the way it should.

And then after all that, there is no DVD, no physical device in case something crashes. The theory is there’s a recovery partition (just like the old PC days), so you don’t need that.

Me being the old IT guy, I don’t trust that, so the next time I downloaded the Lion upgrade, I burned a DVD. The store will let you download the purchase again, but 4Gb still takes a long time, so media is king.

Today I spent an hour or so trying to clean up some iPhone code that I’ve been working on for Carticipate. I found that I was having trouble with the build that I checked out from our Subversion repository for a bunch of different reasons.

The very first one was that the code was built on an older version of Xcode, as well as an older version of the iPhone SDK, and on top of that the build machine was running Leopard (10.5) while I’ve been running Snow Leopard (10.6) almost since the day it was released.

I tend to try and stay as up to date with software as I can, and most of the time it serves me well. In this case, I ran into several very interesting issues. First thing I did was to check out the code using the command line tools for Subversion. After a few false starts, I got the full directory from the server downloaded to my Projects folder.

I opened up Finder, double-clicked on the project file, and got a warning about the file being for an older version of the SDK. Since I had loaded the latest version of the iPhone SDK, it wanted to upgrade the project build files to the new format. I figured that would probably be OK as long as I didn’t forget and check things back in, so I went ahead.

Then hit “build and run” only to get compile errors. Seems a few of the calls on the code that is currently being used in the wild aren’t allowed for the latest SDK. A few edits and no more compile errors, but there’s some other error. By default XCode just shows this little icon at the bottom of the project that shows the number of errors, but you don’t really see the build log. Clicking on the little error icon, takes you to the log, and of course there’s more greek there.

Something about not being able to copy a file from a user directory (one that naturally doesn’t exist on my machine). More web searches and digging around to try and figure out where copies are specified. If you’re OS X centric, it’s really pretty intuitive, it’s hidden somewhere and you have to find the right properties page to update. Finally I find the setting in the build targets, change it to point to an existing file, and everything runs like magic.

Now I notice that on the build machine, there is a Carticipate settings page under the iPhones Settings app, and it looks different than the one that you see if you have a production version of Carticipate from the App store. The one on my machine looks like the production build, so I figure it must be because I’m building for the release target, but switching to the debug target doesn’t seem to change anything.

I stumble around a bit more and find a DebugFiles folder that has the Settings.bundle file with the extra settings on it. Seems like it is set up to copy the file from that sub-folder if I’m building for debug, but no matter what I do, I can’t seem to get it to change. I clean, I build, I switch, I clean, I build, nothing …

Finally just to make sure the files are coming from where I think they are, I edit the root.plist in both Settings.bundles to be different, and … Magic, the debug settings show up. I switch to the release target, and the settings pane changes to the production one. So apparently something in XCode was being lazy, and not copying the file from the DebugFiles folder until I touched it (must use Make under there somewhere).

In the meantime, I see a checkin email from another developer that has the entire build tree being checked in. I dig around on the web some more only to find that the way Subversion is configured out of the box on OS X, there are no default ignores, and apparently XCode doesn’t have any intelligence of it’s own around what it checks in. Turns out there is a  ~/.subversion/config file set up, but the global ignores is commented out so nothing is excluded by default.

By default the global-ignores is commented out, even though it seems to include most everything we would want excluded. I chose to copy the list from somebody else for now, making sure I added one for “build” to exclude that for sure:


### Set global-ignores to a set of whitespace-delimited globs
### which Subversion will ignore in its 'status' output, and
### while importing or adding files and directories.
# global-ignores = *.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store
global-ignores = build *.o *.lo *.la .*~ *~ ._* .DS_Store .Trash* *.pbxuser *.mode*

So all I had to do was remove that build folder from the repository, and give this same change to the other developers … Well, not quite …

After I deleted the folder from the repository, I had the other developer try and check it out. He got these really weird subversion messages that said something was locked. I’ve seen those before, and usually it just means you have to run an “svn cleanup” command to get things back in synch. But in this case that didn’t work, and eventually I found that I had to physically delete the folder on his machine before running the “svn update”.

Oh, and did I forget to mention, the other developer is using an older version of the client, so when trying to update he got this lovely message about his client being too old. We updated to the latest client from the Tigris.org site using the Mac OS X download, thinking that would work. Turns out that this update doesn’t replace the version that comes with OS X (in the /usr/bin folder), so you have to remove or rename that one, and add a symlink to the /opt/subversion/bin/svn executable in order to get the newly installed version to be run at the command prompt.

So with the newly updated checkout, the build worked on all machines, and the repository is fairly clean. Then came the next hurdle, the older machines (running the older version of the iPhone developer kit and therefore XCode) would no longer update the code using the built in subversion client. Found a small message about the version being too old displayed in the status line of XCode, so did some more searching.

Apparently on the older version of XCode, you could tell it which Subversion to use, but at some point, the developer tools started including a subversion library. Still haven’t figure that one out yet, but it looks like it might require some more moving files and setting up symlinks to get it to use the newly installed latest version.

Seems like one thing that I am continuing to learn is that it doesn’t pay to keep your software up to date on a Mac (unless you’re really brave) …

…Or how to brick your phone with an upgrade, and recover…

Earlier this month, Apple released the fifth beta of their 3.0 firmware for the iPhone. As usual, I raced to the site to download it.

I became very excited by the email that I got saying that submissions to the Apple store have to be compatible with iPhone OS 3.0, which to me means it won’t be long before this is a production OS. With that in mind, I strapped on my crazy cap and decided to upgrade my phone to beta 5.

Apple Announcement

After downloading the firmware and software for the new beta, I began the upgrade. According to the instructions, you needed the new beta of iTunes to do the upgrade, so that was the first thing that I installed.

Once that was ready, I followed the process that has become familiar to me for upgrading the phone:

  1. Launch iTunes
  2. Dock the phone
  3. Right click on the phone and choose backup
  4. After the backup click the “Restore” button while holding the option (alt) key.
  5. Browse for the new firmware and watch things roll.

As it turns out, the mistake I made at that point was clicking the “Restore” button, later I learned that beta 5 won’t install unless you click “Check for Update” while holding the option key.

The first thing I noticed was that there was an odd cartoon that flashed up on the screen with a pink background. I figured it was some developer’s Easter egg, so I didn’t worry too much. After the usual series of minutes of resetting the phone and iTunes validating the software, the upgrade told me it was done, and I waited for the final reboot. This is typically the point at which the phone reboots, and iTunes detects it and activates.

Instead I ended up with an endless wait, as the phone never rebooted. So I went through the usual tricks to get it to come back to life. Eventually it worked, and I got a pink screen that showed the graphic you see with a new phone.

I plugged it in again, only to find that it wasn’t recognizing the phone (which after several tries led me to believe that the upgrade was not complete).  Not only was the phone stuck, but I couldn’t seem to get it back into DFU to restore the software.

At this point it occurred to me that perhaps there was something nefarious going on: my phone had been jailbroken prior to the upgrade, so perhaps that was the issue. Luckily for me, I had my wife’s phone to play with, and it hadn’t been jailbroken, so I decided to try and upgrade it.

Unfortunately, that didn’t work, so now I had two phones that were basically useless. Digging around the web, I found some references to problems that people had with updating to beta 4, and a workaround for the pink screen problem. The workaround talked about the problem being related to a change in the USB drivers for OS X 10.5.6 that made getting a phone into DFU mode difficult, so I thought it was worth a try (see: http://gizmodo.com/5166029/how-to-install-unofficial-apps-on-your-iphone-3g-or-ipod-touch-easily-and-safely) .

After downgrading the USB drivers on my Mac, I was able to get it into DFU mode, and restore the 2.2.1 version of the firmware. Inspired by this, I tried upgrading my wife’s phone on a PC (figuring the problem was something in the USB drivers). Sure enough, her phone loaded the 3.0 software just fine.

So, once again, I tried upgrading my phone, and couldn’t get it to go. I tried it on the Mac, then on the PC, same results both times. For some reason it wouldn’t work. I could downgrade to 2.2.1, but not upgrade to 3.0.

More digging on the internet, and I found a posting on the iPhone developer forums that talked about installing beta 4 then upgrading to beta 5 if you have an old silver back phone (both of mine are the metal backed pre-3g phones). I figured it was worth a shot, so I downloaded a copy of the beta 4, and ran the upgrade. Eureka!  The beta 4 firmware upgrade worked !

At this point it had been a few days since I had my phone working, so I took a breath and decided to run with beta 4 for a while. I kept scouring the web and watching the discussion on the beta 5 upgrade problems to see what people were doing to get it to work.

In the mean time, I ran into an interesting (and scary) side effect of the USB driver downgrade. I forgot to upgrade the drivers after my successful downgrade of the firmware, not thinking that those drivers were actually for a different version of the OS. Whenever I plugged a USB stick into my machine, it would go into panic mode and shut down. I thought my hard drive was dying until I realized it only happened when I plugged in a USB stick, and remembered the driver downgrade. Upgrading to the current drivers fixed that issue.

Finally, I saw a post that talked about clicking the “Check for Upgrade” button while holding the option key instead of the “Restore” button. I decided to try this, and was amazed when it worked. So apparently, all along the secret was to use the upgrade button instead of the restore button. There’s some evidence that the reason this fails is because of part of the upgrade to the firmware, so it makes sense that there may be a difference in the way that iTunes processes an upgrade as compared to a restore.

At any rate, my current thinking of the process is as follows:

  1. Download the firmware and iTunes beta
  2. Install the iTunes beta
  3. Dock the phone
  4. Do a backup of the phone
  5. Option click the “Check for Update” button
  6. Choose the beta firmware IPSW file you downloaded
  7. Be happy if it works.
  8. If it doesn’t work, follow the link above to downgrade the USB drivers.
  9. Go through a normal restore (should put you back to 2.2.x)
  10. Repeat steps 5-7

Hopefully Apple will have this all figured out with the next release (and especially before the production update). As near as I can tell, this only affects the older phones, and doesn’t happen with the 3g iPhone.

I’ve been pretty happy with this iPhone OS, it seems to be quicker and more stable than the 2.2.1 was – still looking forward to the actual release.

I have been running my development for VolunteerCake with a database on my Windows box which sits in my office with my Mac. I went to meet some people at a coffee shop, and realized that I couldn’t show them the app running on my MacBook because I was no longer on the same subnet with my Windows box, so I decided to move the database to the Mac to allow me for this.

Since I had everything in place to run Cake on my Mac except for MySQL, the first step was to install MySQL. This turns out to be pretty painless. Just grab the DMG from the MySQL site, and voila, new MySQL running on my Mac. Checked everything out using the MySQL administration tools, and it all looks good (I can access the DB, set up users, etc.)

Next I need to put the data in the database, so I just do a quick export from the phpmyadmin page on the PC. I end up with a file that is the SQL needed to replicate the entire database on my Mac. I run this SQL into the Mac MySQL, and now I have an exact copy of the database on my Mac.

After that, I go to the SQL administrator tool and make sure I have the user set up to give access to that database and make sure the username and password are the same as I was using on the PC (if I were more of a DBA, I’d probably have done this with command line MySQL, but I like GUIs, especially for things I don’t do every day, and the MySQL tools are pretty cool).

Then I need to change my database.php to point at the local database in order for VolunteerCake to get the data from the Mac. This should be as easy as changing the name of the host name to ‘localhost’ from ‘monet’ since I’ve set up the user and access to the database exactly the same as what I had on the PC.

Finally, all that’s left is to fire up the same URL that I have established for my app on my Mac (http://test.lctd.org/VolunteerCake) and … wait, that didn’t work. It says it can’t find the table acos for the Aco model …

Weird, the table is there, I can connect just fine, what could this be? A quick trip to the IRC channel, and I get the suggestion of clearing my cache. OK, try that … But hit the URL again and no change.

OK, now I’m confused, so I try running ‘cake bake’ … Now something interesting: I get an error that tells me that it was unable to connect to /var/mysql/mysql.sock – what does that mean? I thought I was connecting with a TCP socket, why does it want a file? Is this some sort of file permissions issue ?

Back to the IRC chat for some guidance, thinking maybe it’s a common problem, a permissions issue or something, of course they tell me to do exactly what I’d tell somebody else to do: verify that you can connect from PHP first. Good idea – so I whip up a quick connection test page, and get the same error. So now I’ve confirmed that it’s a PHP problem, and not a Cake issue.PHP can connect to a remote DB, but not the one on my local Mac …

Now it occurs to me that I often have problems that end up being related to the open source software that came bundled with the Mac, so I do some Google searches on PHP connection to MySQL for Mac OS X, and with the connection error messages. Eventually I find what looks to be the issue: for some reason the MySQL configuration sets the socket file to /tmp/mysql.sock but the PHP that comes with the Mac is looking somewhere else (at /var/mysql/mysql.sock to be specific). So I basically have three choices, edit the php.ini, edit the mysql config file, or build symlinks to make the file accessible at both locations.

I decide to change the php.ini file, which turns out to be another excercise in hunting, since Mac OS X likes to hide the files you’d expect to find in the /etc directory. After some more Google searches, I find that the PHP5 install that comes with Leopard puts the php.ini file into /private/etc, so I edit that file, changing the part of the file that looks like the following:

To be:

In order to have PHP find the mysql.sock in the location that MySQL is actually creating it. Check my URL again, and voila, everything is working !!!

So, to make a long story even longer, I relearned that mixing actual open source with vendor open source is often problematic. It was suggested by at least one person (Mark Story) on the IRC channel that the best way to set up for Cake development on the Mac is to use MacPorts, since then you end up with matching versions of the software all in a “normal” open source location.

Enhanced by Zemanta