ultravelours_


Panorama

Contents:

Overview
Set up MacPorts
Known problems
Static builds
Universal builds
Files

Build CVS snapshots for 'enblend' using MacPorts

A word of warning first: These are no release versions, they are pulled directly from CVS and may or may not work properly. If there's an offical release for 'enblend' version 3.1, I'll make a stable package – hopefully it won't need any autoconf/automake dependencies.

Also I'd like to point out that I'm not a developer, I'm just packing things up. This ist my first portfile and there might be errors in it that prevent a successful build for you. So far I only tested this method on my PPC PowerBook G4 running Mac OS X 10.4 Tiger.

I try to keep this page "up to date", the last revision is from Jan. 20 2008. I also renamed the port to 'enblend-devel' in order to prevent any interference with the official ports tree, and I think I'll drop the 3.1 version number to clarify that these are snapshot builds.

Overview

There has been some confusion about the current preview versions of enblend, as they were mainly built and distributed for Windows and only a few binaries for Mac OS X have been created. Generally it shouldn't be a problem to compile a snapshot on the Mac, but the program depends on various libraries usually not found on a "stock" Mac OS X install. That makes packaging quite hard (see below).'

Still there are various tutorials to build 'enblend' for your machine, e.g. at the PanoTools wiki. Almost all of them handle the library dependencies by using a package manager like Fink or MacPorts to install the prerequisites and then switch over to a "manual compile". I didn't like this approach, IMHO all dependencies should be tracked by the packet manager – so if you use libraries installed by it, then you should also put your new program under package management.

Set up MacPorts

I use MacPorts, so I decided to write a portfile for 'enblend' (and of course 'enfuse'). It's not that hard, there is a pretty comprehensive guide available. They also have some information on local repositories, which is an easy way to keep the dependencies under control and which is the way to go here.

I'll give you a short step-by-step tutorial to build a current 'enblend' from CVS using MacPorts and dynamic libraries. I'll assume that you already have a working MacPorts installation. If not, visit their installation site.

  1. It's always a good idea to update your MacPorts repository and the installed ports.

    $ sudo port selfupdate and $ sudo port upgrade installed
  2. Now comes the (not so) tricky part that does all the magic. You need to set up a local MacPorts repository. I made a package for you that includes the neccessary folder structure, the portindex, portfile and a patchfile for "semi-static" builds, you can download it here. Just unzip it and put it where you want it to stay, I'd suggest something like '~/Documents'.

    Next you have to tell MacPorts where to find the local repository. Open the configuration file '/opt/local/etc/macports/sources.conf' (you need appropriate permissions) and insert a line like 'file:///Users/_your_username_/Documents/ports', substituting the _your_username_ part with your current shortname. There is already an example that is just commented out.

    You can check, if your local ports repository is found by trying to get info on the new 'enblend' port or list the available variants.

    $ sudo port info enblend-devel or $ sudo port variants enblend-devel

    If MacPorts can't find the fresh port, move to the new port folder (you can drop the folder from the Finder on your Terminal window) and issue the 'portindex' command. If you put the ports folder into your Documents folder, that would be:

    $ cd ~/Documents/ports/ && portindex
  3. There seems to be a bug in the lcms header files, so we install that first.

    $ port install lcms

    According to the PanoTools wiki instructions we need to replace the include statement from '<memory.h>' to '</usr/include/memory.h>' in our freshly installed 'lcms' header file. You only need to do that once (and the statement below should be written as one line).

    $ sudo sed -i= 's/<memory.h>/<\/usr\/include\/memory.h>/' "/opt/local/include/lcms.h"
  4. Now we're ready to go. Install 'enblend-devel' and all other dependencies will be taken care of (that's why I like package management). You can choose to enable the image cache for big file support.

    $ sudo port install enblend-devel +imagecache

    This will take a while. If it is done, you should be able to use your extra-fresh 'enblend'.

Known problems

This method did work for me, but it has a few drawbacks. The biggest problem is, that you don't know the revision you are currently installing or using. Every port install generates a new 'enblend' from probably different sources. There might be a way to include the CVS revision number somewhere in the portfile, but I don't know how to do it. Also I don't know if the upcoming release version will be automatically detected as newer and supersede these CVS build. Due to the current CVS checkout there are no checksums to verify your downloads and as it is not packed in an archive the download is bigger and will take longer. And generally it's "bad style"™ to use current developer versions for this kind of general distribution.

There hasn't been any thorough testing yet (I didn't even try the GPU variant myself), but I'd like to get feedback on how this method is working for you.

Static builds

I really like the way MacPorts work, and one of the greater things is the possibility to create Mac OS installer packages and .dmg images. So I was wondering if that could be another route to build a static version that doesn't need an installed ports infrastructure. Unfortunately this feature doesn't care about dynamic libraries, they are still expected in the usual macports file structure – the apps are linked against libs in '/opt/local/lib' and those required libraries are not packed into the installer package.

The next drawback is the almost non-existant support for static binaries on Mac OS X. Apple doesn't want you to build statically linked apps, you can't just use the '-static' flag. I searched the net and found this site where a workaround is described. You can get "semi-static" builds that only link against those libraries that are included with Mac OS X by Apple (you'll find them in '/usr/lib').

Unfortunately I don't know enough about autoconf/automake to feed the proper libraries to them. The main task would be replacing LDFLAGS referencing libraries (like '-llcms') with a link to the static version (that would be '/opt/local/lib/liblcms.a'). I figured out a crude hack to manually replace the LIB line in 'config.in' – so now the configure script will still check for the dynamic libraries, but the results will be replaced by a list of static libraries. You can see that in my patchfile, and I'd like to learn a better way to handle this.

I've added a variant to my portfile to generate those "semi-static" build (variant "+standalone"), it installs into '/usr/local'. I like that better, as it won't interfere with any MacPorts installation the user wants to make later and it's simply "the usual" place to put your own apps.

Right now most of my libraries from MacPorts are PPC only, I might try to recreate them as universal binaries – but I had some troubles (see below). I added a complete installer package for the PPC version to install in '/usr/local', I created it from CVS (sorry, I don't have any revision number) with this commandline:

$ sudo port dmg enblend-devel +imagecache +standalone

It is linked against these three system libraries:

$ otool -L /usr/local/bin/enblend
/usr/local/bin/enblend:
    /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0,
     current version 7.4.0)
    /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0,
     current version 1.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
     current version 88.1.10)

Generally I'd like to use the MacPorts infrastructure for easy packaging, although I'm not quite sure about any legal restrictions preventing the distribution. If I find some time, I'll try it with Hugin (although the build process seems to be much more complicated).

Universal builds

This turned out to be much more complicated than I thought. Generally, the MacPorts system provides a standard "+universal" variant for all configure based ports. This includes the SDK path to be able to link against the universal versions of the "built-in" libraries, it instructs the compiler to produce a PPC and x86 binary (both 32-bit) and it packages the result in a multi-architecture "fat binary".

Unfortunately it's not that easy, if you need libraries from MacPorts as well. Enabling '-isysroot $SDK_path' treats all other includes as SDK relative path. I don't know how to get around that, so I only tried a dirty hack and symlinked the '/opt' directory (my MacPorts installation prefix is the standard '/opt/local') from the SDK root directory (and deleted it later in the process). You can find that in the portfile, although I commented it out to prevent any accidental damage.

The next problem was a non-working universal 'tiff' port. It did build and install without problems, but the bundled tools and all applications depending on it failed to read tiff files, throwing an error message "Not a TIFF file, bad version number 10752 (0x2a00)". I opened a ticket for that at the MacPorts Trac, but so far I have no solution or workaround for that.

I managed to install a working universal 'tiff' port by manually applying the patches another Dominik made. You need to split the process into two parts. First download, extract and configure the sources with

$ sudo port configure tiff +universal

Then open the resulting 'tif_config.h' and 'tifconf.h' in your favorite text editor and fix the endian-related statements. Finally you can finish the installation with the usual

$ sudo port install tiff +universal

MacPorts will see that it already prepared and configured the port and continues just where it left off. With a working 'tiff +universal' port, it is possible to create a standalone installer package for 'enblend' including a x86/PPC "fat binary".

I still don't get a working DMG from MacPorts. After creating the disk image, it complains about having "No space left on device". DMG creation works fine for other ports, so I'll investigate that later. The installer package is fine and for now I manually create the disk image.

Files

©2008 Dominik Schlütter, dev@ultravelours.com