Running Perforce on FreeBSD 10

Yesterday I updated our company server to FreeBSD 10. It went pretty well with only a few glitches: had to remove libiconv (documented in UPDATING) and some of the ports (such as Perl 5.16) needed manual recompilation as portupgrade failed on them.

But I quickly discovered that Perforce does not work – attempting to start the server produces the error message:

Shared object "libstdc++.so.6" not found, required by "p4d"

The reason is that FreeBSD 10 includes a new C++ stack and gcc, including libstdc++, is not installed by default.

So the problem is easy to fix: install lang/gcc from ports. This will bring back libstdc++ and Perforce will run smoothly again.

Update 4/23/2014: Perforce version 2014.1 has a FreeBSD 10 specific build, which does not depend on libstdc++.

Solved: C1 Crashes with Images on an AFP Share

I originally posted the following on the Phase One forums.

I almost pulled all my hair because of this issue, so I thought the solution could be helpful for others (especially FreeNAS users).

The problem:

I recently moved to storing all my RAW files on a central server in the studio to be able to access them from my Macs as well as a Windows notebook (which I use on the field during trips). The server is a beefy machine, with dual gigabit Ethernet connections and an 8 disk super fast ZFS array. It runs FreeBSD 9.0 with Netatalk 2.2.1 for file sharing towards Mac clients and Samba 3.6.3 for Windows file sharing. It could serve files faster than the local SSD disk in my Mac… Basically this is the same software stack you get when you use FreeNAS.

From Windows 7 running the 64-bit version of C1 everything was fine, but when I worked on my files from a Mac then C1 crashed every 5-15 minutes bringing down even the Mac (I had to pull the plug several times because even shutdown didn’t work). Frankly I was unable to work at all with C1 from Macs (running OS X 10.7.3).

The server’s log was full with the following error message:

afpd[6065]: sys_getextattr_size: error: Result too large

The solution:

After hours of debugging the solution is really simple: you have to add the “ea:ad” parameter to the shared volume’s config line in AppleVolumes.default.
The line for my Photos share is the following:

/tank/Photos ea:ad options:upriv dperm:0700 fperm:0600

No more error messages, and C1 6.3.5 shines! I’m a happy user now :D